App-V 5: Application Troubleshooting: “Fly-by-Night” Error Messages

To continue the discussion of application troubleshooting, I wanted to provide some clarification on a certain type of application failure. In a blog post a while back (https://blogs.technet.com/b/gladiatormsft/archive/2013/05/15/app-v-process-exit-codes-and-why-they-matter-when-troubleshooting-virtual-applications.aspx) I discussed using Process Monitor to dissect silent application failures or exits. Process Monitor allows us to look at process exit codes to determine leads on application failures. I wanted to dive into another type of failure that may or may not leave a proper exit code because it is not “completely” silent. It’s what I refer to as a “Fly-By-Night” error message. [Incidentally, it should be surprising to no one that a blog such as this would eventually have a subtle reference to the rock band Rush.]

Fly-by-Night Error Messages refer to those error messages which appear to flash some code but is often interpreted by the human eye as a quick flash of a black screen:

 
Fly-by error messages occur when you try to call a script, batch file, internal command (using CMD.EXE triggered by CONHOST.EXE) or any type of Win32 Console application (also triggered by CONHOST.EXE)  and it fails to launch.
If you are lucky, these can easy to troubleshoot if you attempt to launch the application without requiring a console host process to launch it (CONHOST.EXE.) For example, let’s use the example of the DB2 client. You have virtualized the middleware and you are attempting to run the Batch file that triggers the DB2 Command Prompt Plus (CLPLUS.BAT.) You simply run the path to executable within an already existing command prompt to grab the error message.

 
I usually just copy the Start in directory path and change to that within the command prompt. Then I run the executable. This is usually in the Integration path and not the immutable package cache.

 
In the above example, it looks like the issue is pretty straight forward. The application requires Java and I do not have Java installed locally or virtually.  In most cases, you will get an error message in the console – straight forward or not – you will still have something to go on.

So what if this yielded no error?

You now have a silent exit on your hands. If you do not get an error message at all, you will need to investigate it further using Process Monitor and I recommend referencing my previous blog on silent exit codes (see link above.) For example, if I get a silent exit from a console-based application, I will first load my filter for major process operations – filtering on PROCESS CREATE, PROCESS START, LOAD IMAGE, and PROCESS EXIT.

Assuming I stopped the trace right after the error, I can then start at the last exit of CONHOST.EXE and work backwards towards the exits of the CMD.EXE and the actual console application. If this were a batch file, it would just be CMD.EXE. In the example above, it is the db2cmd.exe process. In the above example, the exit code for db2cmd.exe was -2029059760.

 
Translating this error code to its system message yielded that it was caused by an operation not being supported on a directory.

[Incidentally, this was an easy fix (thank you VFS Write Mode.)]