After Restart: No valid themes are found on this instance (intermittent)

I post this bug here after the same bug that was posted on GitHub got closed by a very unhelpful admin
https://github.com/salesagility/SuiteCRM/issues/6444
This forum’s bug section is closed and says “post in github” so I am a bit surprised by this

Issue
This started happening today after I rebooted my computer
Whenever I try going to SuiteCRM or accessing its REST svc a response of “no valid themes are found on this instance” is returned. This happens intermittently and if I keep reloading it manages to load SuiteCRM some times. But then the issue appears again. I tried rebuilding and repairing but it dind’t work

Expected Behavior
SuiteCRM should load/ REST svc should reply

Actual Behavior
“no valid themes are found on this instance” is displayed in browser. Nothing is logged in logs

Steps to Reproduce
No way to reproduce as it started happening after rebooting for no reason

Context
It has completely broken SuiteCRM
HIGH

Your Environment
SuiteCRM Version used: 7.5.1
All browsers & REST svcs
SQL SERVER & IIS with PHP
Operating System: Win 7

Actually Dillon is a very helpful admin. :slight_smile:

The general idea is that things only go into Github when they are known to be a generic problem with SuiteCRM code, not when we are still trying to figure out why one single system started misbehaving. We do that work here.

The part of your problem that I find most intriguing is the fact that it is intermittent…

Can you please try these measures:

  1. Other repairs from Admin / Repair (not just Quick repair and rebuild)

  2. Deleting “cache/themes” folder (it will get re-created)

  3. You need to check both your logs. For Windows, the web server log might be a little harder to find. I believe it is in the Event Viewer. Try Googling about this to find out, in respect to your specific system.

  4. Suspect other kinds of causes: intermittent disk failure; anti-virus or other process locking the files that SuiteCRM needs to access; faulty network devices, etc.

I have a couple of further suggestions, but please investigate these first. Good luck!

Apologies… I got frustrated because the last thing I needed yesterday was this ghost bug

I tried all of your fixes with no success
The logs (c:/windows/temp/php53_errors.log) have nothing either

I strongly suspect that this is caused by an antivirus/policy process since I am on a corporate network and this started happening after restart (when updates get installed). The fact that this started simultaneously happening to 2 SuiteCRM instances reinforces this theory

I wonder why this is only happening to themes and not to everything else though. It is a bit strange that this started happening now. I’ve had these 2 instances installed for 2 years (dormant) and just recently had to revisit this project as we are developing a proof of concept to replace DynamicsCRM. It would be very bad luck that the only antivirus update that broke this got installed precisely now

I am clueless and fear the IT department is just going to shrug this off

Update…
Upgraded PHP to 7.0 just in case but this didn’t fix it either (same error)

Ok, I have a suggestion for you.

Download SysInternals Suite from Microsoft’s web site.

Run Process Monitor and attach it to your PHP process (or it might be your IIS process, I don’t know), whichever is reading files from disk in order to serve your pages.

Now add as many filters as needed to narrow down the output to what you need. You should be able to examine the actions of the process on the file system, and see exactly what is wrong (permissions/locked file/disk erorr/etc).

You can also use Process Explorer (also in the same Suite) to search for file handles, and it will tell which process is holding which files.

GOOD NEWS! I was able to fix this

Thanks so much for your help, patience and suggestions. And once again apologies for being impolite when first posting

I will describe below what fixed it in case anyone encounters this again…

STEPS TO RESOLUTION:
1 - Upgrade PHP to 7.0 (PHP 5 wasn’t letting me do step 2)
2 - Very painfully upgrade SuiteCRM (in my case from 7.5.1 to 7.7.9). Very painful process as I got some “no valid theme” msg at a couple points and had to resubmit the post request via browser refresh). I made sure to run this on my backup first just in case

After this the issue is gone

My guess of what may have happened is that my disk is corrupt somehow and new files from upgrade have landed on a safe part of it. Who knows!

You should still try to figure out what went wrong… otherwise you can’t trust your server anymore :ohmy:

If you had disk errors, they are logged in Event viewer, “Windows Logs\System” folder. You can also run a check disk.

Keeping your PHP and SuiteCRM updated (beyond 7.7.9!) is an essential security procedure. There are countless security and bug fixes in all the releases you’re missing. It’s really easy to attack any old unpatched system. I know upgrades can be “painful”, as you write, but it’s better to go through that pain early, and do it calmly in a test system (a clone of production), than wait for some real problem to land on your lap when you least expect…

Anyway, I am glad you got it working. :slight_smile:

I will look into this as you suggested as I feel uneasy knowing it could happen again. Windows Logs show no disk errors. I’ll run a disk check tonight

At the moment the “server” is my desk computer and I am planning on using SuiteCRM to replace the server-side of MS CCA framework that uses DynamicsCRM

If and when this proof of concept gets approved I will most definitely upgrade to latest versions and likely sign up for support. Right now it just doesn’t make sense as SuiteCRM is my entity-holder (designed 2 yrs ago) and its UI isn’t even displayed

1 Like

Here is one more update

After Upgrading to 7.10.10 the issue started happening again

In fact I think that it never went away, it’s just that in previous versions I was getting a 500 error instead of the themes not valid error

After losing hope I decided to install Apache and run the exact same instance there. This fixed it

I am convinced that the error was linked to my user’s group policy so this should be super rare. At least there is a solution (using Apache)