It's easy to forget that beneath all of the configurations and code files and frameworks that your code runs on a regular computer that follows regular computer rules.
After a coworker of mine merged in a branch containing a Sitecore upgrade, he started getting the dreaded "Required license is missing: Runtime" error.
We checked all the normal causes for this problem:
- License file was in the /data folder.
- License file was not expired.
- Path to data folder (
<sc.variable name="dataFolder" value="/data" />) in
App_Config\Sitecore.configwas pointing the location of the data folder with the license file.
- Security on the data folder and license were set to allow access (usually on dev environments I grant
Everyoneto save me any hassle).
I would have checked
/sitecore/admin/showconfig.aspx to see if something was indeed messing up the
datafolder parameter, but of course Sitecore won't load any page when the license file is missing.
We searched the
App_Config folder for any instances of the text
dataFolder (shoutout to grepwin for easy grepping without command line), but for various reasons his installation contained over a dozen folders with that string. We could have crawled through them, but I hate looking for a needle in a haystack when there's a very real possibility that the needle isn't there.
So I turned to one of my favorite tools: Process Monitor (procmon). Brought to you by the same folks who brought us Process Explorer, procmon lets you monitor virtually anything the processes on your computer are doing. Procmon logs and shows you every time a process
- Accesses the registry.
- Accesses the file system.
- Accesses the network.
- Creates or exits a thread.
Procmon captures a lot of events. After leaving procmon open for one minute, it had captured over three million events.
That's a lot of events!
We configured the filter to only show file system activity for
w3wp.exe where the path contained the text
license.xml (you could also narrow it down to the process ID of the specific app pool you care about, which could be useful if trying this on a shared dev server):
Sitecore tried 74 times to load the license file!
And voilà, procmon clearly showed that Sitecore was looking to a different path than we expected! It turned out that the developer who coded the upgrade branch had inadvertently committed his
App_Config\Include\DataFolder.config with a hard-coded path. As we didn't need the separate
DataFolder.config file, we just deleted it and used the
datafolder parameter in
App_Config\Sitecore.config that was already templatized*.
Certainly using procmon in this way is a bit overkill. We would have found the offending config file if we'd simply checked all the config files we found when grepping the
App_Config folder. I find it helpful to remember to peek under the abstractions we rely upon to see the nitty gritty that lives under our fancy-pants applications.
* If that's not a word, it should be!