What I wanted was to find the calls to CreateFile for the licence file and then see what happened after that, again comparing good and bad procmon traces. To this end I used WinAPIOverride (available here). In order to understand even more of what a process is doing under the hood, you need to use an API monitor program that has the ability to hook any API call available. Now whilst procmon is a simply awesome tool, such that life without it would be an unimaginably difficult place, it does unfortunately only tell you about a few of the myriad of Microsoft API calls. The same happened when running as an administrator so it didn’t look like a file permission issue.

However, in the App-V version it wasn’t reading from the file (a ReadFile operation) but no CreateFile operation was failing so I couldn’t understand why it wasn’t even attempting to read from the file when it didn’t appear to be unable to access it. In the working trace, you could see it open the licence file, via a CreateFile operation, and then read from the file. As I knew what the licence file was called, I honed in quickly on this in the traces. I therefore ran up the trusty Process Monitor (procmon) tool to get traces on the working and non-working systems so I could look for differences.

I was recently tasked to investigate why an App-V 5.1 application was giving a license error at launch on XenApp 7.8 (on Server 2008R2) when the same application installed locally worked fine.

Process monitor boot logging