Archive

Posts Tagged ‘troubleshooting’

On Debugging Virtual Applications: Part 1: Overview (or Let’s Start at the Beginning)

February 19, 2016 4 comments

For many application packagers, virtual application sequencers, and general IT pros, the concept of actual “debugging” can take on many meanings. Often the words “troubleshooting” and “debugging” are interspersed – especially when reading articles and blogs dealing with the topic of trying to dissect what may be occurring when a virtual application is not functioning as expected. When we speak of the word “debugging” in the context of its meaning with regards to programming and compiled software code, it is simply the dissection and reverse engineering of binaries to determine the root cause of an issue or basically “find the bug” in the code.

The level of depth may vary depending on the tools being leveraged and the amount of access to code or symbols. For example, open-sourced code projects on the web are very easy to debug because – well – the code is distributed alongside of the binaries. In addition, special files called “symbols” are also often available if need be. This is especially helpful in the world of Windows debugging. For Closed-Source binaries – like Windows, access is limited to what API’s are exposed and documented within MSDN, the SDK’s, and publically available symbol files. Still, this tremendously aids our ISV partners when they are troubleshooting issues with their own code running on top of the Windows platform.

Enter the Virtual Application

What makes this especially complex in the world of virtual applications is that the surface area expands to not only include the original application but also the virtualization engine that is maintaining its sandbox – specifically its isolation and/or state separation mechanisms. With this, you have essentially increased your variables for issues. Whereas a native application involves one vendor; running on top of another vendor’s operations system, a virtual application now deals with potentially three different vendors (not even counting the potentially amount of 3rd-party vendors that could also be hooked into the kernel via filter and device drivers.) In the case of Microsoft and App-V, if the application being virtualized is a Microsoft application, there are unlimited resources internally to work on that application. In most cases, that represents less than one-hundredth of one percent of the applications out there in the ecosystem – at best. Most cases, the application is external. When that is the case, the debugger must determine the following:

Is the application open sourced or closed source?

If the application is open-sourced, the application can be easily investigated alongside the virtualization subsystems and likely debugged pending that the individual doing the debugging understand the source code and has the proper tools to debug the application from within the share operating system (in the case of App-V – that would be Windows.)

If the application is closed source, what resources are available from the vendor?

This is where it can be challenging. When you are debugging a closed source application running virtually, it requires significant insight into the application – especially if the application is running in native code. While Microsoft makes public symbols available for ISV’s to help with debugging, often the opposite is not true. As a result, the debugging is “best-effort” at best and is usually limited to basic reverse engineering tools like Process Monitor, API Monitor, or DbgView. One exception to this – that I have encountered – have been situations where the application encounters specific issues when virtualized – and those issues cannot be reproduced on a natively installed instance of the application. In those cases, the focus can shift to the virtualization engine however, even in these situations, working in triangulation with the application vendor yields more success – much quicker.

Is the application using a 3rd-party application virtualization engine by a vendor different from the vendor of the underlying operating system?

In this scenario, the application is written by one vendor, running on top of an operating system by a different vendor, and then sandboxed using an application virtualization by yet another vendor. In the case of Windows, the application is using a non-Microsoft virtualization solution. There have been many times where I was working support for App-V and a customer would call in with an issue they were having virtualizing a version of Office or Visual Studio on a non-Microsoft platform. I would always re-direct the customer to the vendor of the app virt stack – even though we were the vendor of the application being virtualized as well as the underlying operating system. I would then direct the customer to reach out to the Office or Visual Studio team as well to work in triangulation.

Relationships of Application to Support Vendors

When debating the best source for debugging virtual applications, please feel free to leverage the following matrix I constructed to assist you in reaching out to the most likely resources that will be able to help resolve the issue.

 

Application Vendor

Operating System Vendor

AppVirt Stack Vendor

Best Vendor(s) for Virt Debugging

Best Case Scenario

Vendor A

Vendor A

Vendor A

Vendor A

Rare in the Windows World

Vendor A

Vendor B

Vendor A

Vendor A

Typical 3rd-party AppVirt Scenario

Vendor A

Vendor B

Vendor C

Vendor C first & Vendor A optional

Most Common at Microsoft

Vendor A

Vendor B

Vendor B

Vendor B first & Vendor A optional

 

 

 

 

 

 

 

 

 



The reason I make the above recommendations is because at some point the application, the application virtualization engine, or even perhaps the operating system may require some debugging – especially if there is a potential bug. If the resources troubleshooting the issue do not have access to the resources and tools needed to debug the issue – then you are essential throwing darts against the wall – and it will lead you potentially down a rabbit hole.

Why Discuss Debugging?

I have decided to start discussing the topic of virtual application debugging to serve the following purposes:

  1. To demystify the concept for application packagers and IT Pros in the Application Virtualization space. There are tools and concepts that can help these professionals to further arm their skills and enhance their arsenals and toolboxes.  Many reverse engineering tools such as ProcMon can only go so far.

  2. To aid software vendors in how to debug applications running under App-V and how their applications may be affected.

  1. To aid customers in how to gather and collect the appropriate debugging information to help Microsoft and other software vendors diagnose issues, isolate root cause, and resolve problems and bugs quicker.

Next Up Part 2: Types, Modes, and Situations

Application Troubleshooting: An Error Message, Without Context, is Worthless


Note: This blog contains free stock photos that were too hilarious to pass up.

I was inspired to write this article based off an internal discussion I was involved with where someone was requesting a comprehensive list of all possible event log messages delivered in Windows Server. I have always been interested in the reasoning behind an “ask” such as this because it could be misguided. Where to begin? First of all, it is quite a loaded “ask” as it is not specifying whether we are talking about all of the in-box default error messages relating to Windows – the operating system specifically, or are we also talking about all of the roles and features which also contain event providers? Where would all of these go? What would this be used for? Second of all, what is the purpose?

iStock-Unfinished-Business-10

Answers always baffle me: “Oh, for the help desk.” “As a reference.” “For our in-house troubleshooting guide.” The last example leads me to what often results in a bi-directional obtuse conversation where I re-ask what are the use cases and contexts of these error messages. Will the person requesting the error messages also be attempting to follow-up on each error message to determine all of the possible situations in which these may occur? That would be quite an insurmountable task. In most cases, no, these will be either copied-and-pasted into a “guide” – sometimes even being printed out into a very thick, but mostly useless material reference.

HRESULTS vs. Event Logs

First of all, the event log message tells you everything you need to know about the ERROR itself. This has evolved significantly over the past decade with advancements in the Windows. Often, you will get errors/exceptions thrown from an application and the level of description will depend on the generosity of the programmer/developer of the application. One thing is for sure – at the very minimum in most cases, an integer-based or hex-based response will occur. The most common of these are HRESULTS. A few years ago, due to the nature of overlap between operating system components and external software, a tool called ERR.EXE was made available on the Microsoft Download Center (http://www.microsoft.com/en-us/download/details.aspx?id=985.) This tool parsed all of the known header files for windows and applications to provide the corresponding strings and descriptions of known HRESULTS and error codes within the Microsoft software ecosystem. The use of the utility would yield all known matches such as the example below:

err1

This utility was especially useful because it could also automatically translate the decimal-based equivalent of an HRESULT:

err2

But . . . Here’s the Thing. Where do you go from Here?

Well, how did you get there? What was occurring when you encountered that error? For example: Let’s say you get an HRESULT 0x80000005. You use the ERR tool (or you know from memory) that it is “Access Denied.” What was occurring when this happened? Let’s say this occurred within an application. You could then leverage Process Monitor or another tool to trace the issue to see what it file/registry entry/etc. the program was trying to accessed. There is no way to give anything more than a generic recommendation without additional context related to the error.

In the case of an event log entry, there is much more information. The source component, Event ID, description, and more – along with additional XML detail. In the example below, what else would you gather from this simply looking up Event ID 36888 other than what you see in the dialog boxes?

event1

That is where the scenario in which it happened plays an important role in determine what the root cause of this error is. In some cases, only one situation warrants a particular error and resolution. These are the ones we love – yet they are rare. In most cases there will be more than one scenario.

Why are Some Event Messages More Descriptive than Others?

Like with applications errors, event log entries vary regarding the degree of detail. In many cases during the development and evolution of a component, particular errors are hypothetically conceived during the development cycle and are laid out with the event tracing framework. These get further nailed down in the test and beta phases and the events are adjusted accordingly. At the release time as many clear-cut, known issues are mapped out through release notes and knowledge base articles. This process continues through the lifecycle of the component or software.

iStock-Unfinished-Business-9

But again, these are only events. On all of my machines I have ever worked with, I would venture to say that I have only ever encountered a small fraction of all of the potentially available windows events which warrant errors or warnings. There are easily over 200,000 ETW and legacy windows events. Why reinvent the wheel and create a huge list for searching when you already have BING at your fingertips. And with Bing, you can search the event\error with additional contents.

What is probably the most beneficial troubleshooting assistant is the known resolution – in the form of a knowledge base article. The “Symptom(s)” section of most types of knowledge base articles is where the context is mapped out with as much detail as possible. It is usually in the form of “You are running [SOFTWARE\COMPONENT] and you are performing [ACTION]” or “you are attempting to [CONFIGURE\LAUNCH\RUN\CLICK ACTION] and you encounter the following [ERROR\MESSAGE]

iStock-Unfinished-Business-2

The Symptom(s) section is usually followed by the “Cause” section. Often this section is prefaced with “This issue may be caused by . . .” indicating that this may not be the only cause of the issue. Yet this particular cause will be remediated\resolved by the “Resolution” section. That format is what makes the knowledge base article so great. It cuts right down to the break-fix scenario. Symptom-Error-Cause-Resolution.

Building knowledge bases “from the error up” is not an optimal way of building out a framework for a help desk. These are built and drive by the overall experience of the issue itself. Working in support for many years, one of many elements that separated the true escalation engineers from what could automated with a diagnostic utility or front-line support was the ability to resolve an issue for the first time. While the first question was usually “What’s the Error Message?” it was the second question that was most important – “What were you doing?”

iStock-Unfinished-Business-3

App-V 4 Application Troubleshooting: Breaking Down Virtualization Issues Pt. I

August 27, 2014 1 comment

If you are working with an application that has been virtualized with App-V 4.x and that application is not functioning as expected, one of the first steps in troubleshooting should always be to try to determine if the issue is related to sequencing or related to virtualization. For the standard application, Devirtualization is pretty straight-forward and pointed out in the following article:

http://blogs.technet.com/b/gladiatormsft/archive/2013/10/26/appv-on-devirtualization.aspx

One you have determined that the issue is likely a virtualization issue (done by successfully de-virtualizing using the article above) then you can proceed to quickly troubleshoot the issues further using a variety of approaches. One good source for V 4 troubleshooting is John Behneman’s post on the App-V team blog: http://blogs.technet.com/b/appv/archive/2012/11/14/3494514.aspx

You can also take this further by enabling the SFTLDR unhandled exception log (SFTLDR.LOG) which tracks hidden errors within the SFTLDR hook DLL which is the most critical virtualization DLL.

To enable the SFTLDR.LOG, create a string (REG_SZ) value called UnhandledExceptionFilterLocation within the following registry key: HKLM\SOFTWARE\Microsoft\SoftGrid\4.5\SystemGuard

For the Value data, you will want to put in the path to an existing directory that is at least one level deep from the root of the drive (i.e. C:\\TEMP\\SFTLDR.LOG.) Also note that I have to double the slash count for paths.

The SFTLDR.LOG file looks like this:

 

[08/27/2014 18:21:26.379] [03ac] [0a38] [Q:\KK_HAWT.BTY\LISTA\RUN\FIRST\hail.exe] HookedLoadLibraryExW. lpLibFileName=Q:\KK_HAWT.BTY\LISTA\RUN\FIRST\test.dll
[08/27/2014 18:21:26.379] [03ac] [0a38] [Q:\KK_HAWT.BTY\LISTA\RUN\FIRST\hail.exe] HookedLoadLibraryExW: SXS start
[08/27/2014 18:21:26.379] [03ac] [0a38] [Q:\KK_HAWT.BTY\LISTA\RUN\FIRST\hail.exe] HookedLoadLibraryExW: No mapping for Q:\KK_HAWT.BTY\LISTA\RUN\FIRST\test.dll
[08/27/2014 18:21:26.410] [03ac] [0a38] [Q:\KK_HAWT.BTY\LISTA\RUN\FIRST\hail.exe] HookedLoadLibraryExW: LoadLibrary failed (1). dwLastError=14001

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 (http://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.)]

App-V 5: Application Troubleshooting: On the Origins of an Error Message

May 12, 2014 2 comments

Have you ever been testing a virtualized application and it fails with a bizarre application error that is either extremely vague (unknown error) or coupled with some random hex code? Your first reaction usually is “Where’d that error come from?” That is a good reaction to have as it is the first major hurdle in determining how to troubleshoot what has gone wrong. If you have not narrowed down the target of where the application error is coming from, you leave yourself open for spending a tremendous amount of wasted time down “troubleshooting rabbit-holes.”

Is it an App-V Operational Issue?

The first thing you will want to narrow down is whether or not it is an operational issue coming from the App-V Client itself, or is it related to the package (Application not functioning as expected.) I always recommend to first look at the source of the error window. If the error message is originating from a “Microsoft Application Virtualization” window, it is likely an operational issue tied to one of the client engine components or perhaps a streaming issue.


If it looks to be an operational issue, I would advise you leverage some scripts and tools written by Dave Falkus, one of my colleagues in the UK: http://blogs.technet.com/b/virtualworld/archive/2014/04/12/app-v-5-0-etw-tracing-automation.aspx

In addition, one of my previous articles will assist you in dissecting App-V error codes: http://blogs.technet.com/b/gladiatormsft/archive/2013/11/13/app-v-on-operational-troubleshooting-of-the-v5-client.aspx

So I’ve determined it is an error that occurs within the virtualized application itself, now what?

Whether you are isolating an issue that may be caused by virtualization or by bad sequencing, if you have determined the error is coming from the virtual application then it is time to start doing a little reverse engineering with a couple of Sysinternals tools. The first thing I do for an application completely new to me is map out the EXE and DLL launch tree. You can do this by capturing the issue with Process Monitor ensuring that you start capturing at application launch.

You can then run a quick capture filter (I usually load a saved filter with these filter settings)

My filters contain these operation events:

  • Process Create

  • Process Start

  • Load Image

  • Process Exit

If the application is devirtualized on the sequencer, you will be looking to start from the shell process that initiated the Process Create operation (CMD.EXE or EXPLORER.EXE likely.) On a side note, svchost.exe will spawn modern apps, but that is out of scope here. J

If the application is running virtualized on the client, you will see that the AppVClient.exe process interjects spawning the mavinject32.exe or mavinject64.exe process depending on application bitness – followed by the shell creating the process. The example below using virtualized SongSmith displays this in Process Monitor:

Incidentally, if you want to know more about how the AppVClient.exe determines when to run the MAVInjector, read this previous article:

http://blogs.technet.com/b/gladiatormsft/archive/2013/09/12/app-v-5-to-virtualize-or-not-to-virtualize-how-app-v-5-answers-that-question-when-you-launch-a-shortcut.aspx

OK, I have identified the EXEs and DLLs, Now What?

You can do one of two things. You can search the Processes for strings using Process Explorer, or in the case of DLLs and EXE’s, you can simply leverage the Sysinternals STRINGS.EXE tool. The Process Explorer tool is great for finding error strings (by going to the properties of a process, selecting the “Strings” dialog box, clicking the “Find” button.)

The reason I do not use this is because it requires the process to still be active and it is not easy for searching DLL modules if they are not still in memory. I use instead the STRINGS.EXE utility (http://technet.microsoft.com/en-us/sysinternals/bb897439) as it allows for more search flexibility.

Case in point, this bizarre error in Notepad++:

I can confirm the error came from the EXE NOTEPAD++.EXE by using the following command:

Strings-o “C:Program FilesNotepad++Notepad++.exe” | findstr /I scintilla

  

Putting it All Together

When you get that unknown application error, you can then proceed to investigate towards a resolution using a clear path by:

  • Determining whether it *IS* an application error and not an operational error.
  • Determining if it is a sequencing or virtualization issue.
  • Collecting the Process/DLL load/execution order.
  • Identify which EXE or DLL is contains the error string.

 You can then proceed to continue troubleshooting by focusing around that EXE or DLL with Process Monitor, SpyStudio, APIMon, or whatever tool you prefer to further debug the issue.


Enabling Advanced Windows Installer Logging

March 17, 2014 3 comments

Throughout my tenure while working in support, I would occasionally come across issues where the issue I was troubleshooting with a particular product was the actual installation. Too often the error would be some generic error (with an error code of 1603 or something similar) or one of those “unexpected errors.”

One way to get to more detailed information was to enable advanced debug logging of the Windows Installer service. You can enable advanced logging for a particular package by using the following synatx when attempting to run the installation:

Msiexec /i <path to your .msi package> /L*V C:\Setup.log

where the “L*V” is what enables the Windows Installer to create a verbose log file.

But what if you want to turn on debug logging for not just the packages being installed, but also for the Windows Installer service itself? This was used to isolate the strict name checking issue with App-V 5 MSI wrappers. You will need to do what we call the “Voice Warmup” trick. It gets its name from the fact that enabling all options spells out “voicewarmup.” To do so, do the following

1. From an elevated command prompt, stop the Windows Installer Service if started:

net stop msiserver

2. Open up the Registry Editor.

3. Navigate to the HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer.

4. Create a new string value (REG_SZ) called “logging.” (No Quotes)

5. In the data field, type “voicewarmup!” (No Quotes)

6. In the same key, you will also need to create a new DWORD value called “debug.”

7. In the data field, type “7.”

8. Exit the Registry Editor.

9. Restart the Windows Installer Service.

net start msiserver

After you install (or attempt to install) the application, the log files will be located in %TEMP%.

I would advise not keeping these values in place on a production server.

App-V: On Operational Troubleshooting of the V5 Client

November 13, 2013 10 comments

 Update 12/6/2014: The App-V 5 logs have been consolidated and are organized differently as of App-V 5 SP3 – but the event and event formats are still the same. Please read more about it here: http://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_event_logs_moved

Whenever I am doing customer engagements, I find it always valuable to ensure that the customer has a plan in place for ongoing support. Having my origins in support myself, I can relate to the customers concerns with impact to their helpdesk. Especially when a new product has been introduced in their ecosystem.

In the world of App-V, we divide up troubleshooting problems in two ways: 1) troubleshooting the operational client engine and 2) troubleshooting the application itself. IT departments relegate level 1 operational troubleshooting to their helpdesk team. This requires training your helpdesk with FAQs, CubeNotes, flowcharts, etc. to resolve basic issues and to at the very least, gather the necessary data to help higher level escalation teams isolate the problem.

Training or Retraining your HelpDesk on App-V 5

The App-V Client will be a very different experience for your help desk in terms of toolkit. Conceptually, they will be doing a lot of the same thing but the way they do it will be different.

Package Repair

Repairing a package will still be needed, but instead of using the client UI (which is deprecated in App-V 5.0 SP2) or SFTMIME, you can use the Repair-AppVClientPackage to reset user and or package state. You get can get specifics on this by reading Ryan Cobb’s blog post on the subject here:

http://blogs.technet.com/b/appv/archive/2013/10/28/how-to-quickly-repair-published-app-v-packages.aspx
 

Also NOTE: I have seen information out there stating that you can also simply delete files directly in the native locations. That is true but this command is much cleaner and useful for the help desk professional. You should also never, ever, ever, ever, ever, ever, ever delete the VFS directories manually as this will also create problems by potentially breaking the user mode VFS and copy-on-write mappings for the application. If you suspect issues with those VFS directories, use the Repair-AppVClientPackage command instead.

Connection Group Cleanup

The same options available for an individual package are also available for a connection group using the Repair-AppVClientConnectionGroup command. In fact, you should be advised that if you repair the connection group instead of the individual packages when you are experiencing issues where you would normally repair the application, this will purge out all of the settings for all applications within the connection group. If there are applications currently in use and it is preventing you from running these repair operations you will need stop all of the package processes. Stop-AppVClientPackage will stop all virtual processes in a package and Stop-AppVClientConnectionGroup will stop all virtual processes in a group.

App-V Client Logs

The SFTLOG.TXT is gone. So are all of the other text-based logs. Knowing how to collect good log data is essential to every help desk professional especially if escalations will be involved. The good news is everything is now logged to event logs. You can view these by opening up the event viewer and navigating to Applications and Services Logs – Microsoft – AppV – Client. The default view will show the three basic event logs: Admin, Operational, and Virtual Applications.
  
 

If you would like to view the additional logs that can enabled, navigate to the view menu and select “Show Analytic and Debug Logs.” In many cases, you may need to take advantage of these.

 

As you will see, there are a tremendous amount of additional logs. Most of these are not enabled by default. You will have to expand the folder, right-click the log and select “Enable Log” to enable it. Be careful turning on a lot of these as it can potentially affect performance.

Which Log do I Use?

Well now that will depend on the type of issue that is occurring be it an error upon publishing, streaming, launching, client service start-up, etc. often, the basic logs will give you what you need to know to fix the issue, but when it doesn’t, it is time to investigate further and these additional logs can come in very handy. The question is, which log or logs should I enable? The actual error message or error code may quickly provide some insight.

The App-V 5 Error Code

Like I did in V4, I am not necessarily concerned with the entire error code. I usually only have to pay attention to the last 10 digits when looking at V5 errors ONCE I have the error in the correct Hex format. Often time, in the event logs, the error code is actually in decimal format. One of the first things you will want to do is get the error in its correct format. For example, if you see the following error in the event log:

64 notification failed with error 5746720685053444123, Package <GUID>, version <GUID>, pid
<PID>, ve id 0

The first thing I do is convert the decimal error over to hex.

 

5746720685053444123  translated to hex is 0x4FC074040000001B.

If you break it down first separating the last ten digits (04-000000001B) you diagnose this further by resolving the first two digits to the component using the table below:

 

Hex
  Code

Category

Where you might further Info

01

Integration

Client-Integration Log

02

Orchestration

Client-Orchestration Log

03

Client Service

Client-Service Log

04

Virtualization Manager

Client-VirtualizationManager Log or Client-Vemgr Log

05

Shared Components

Admin and Operational Logs

06

Catalog

Client-Catalog

07

Publishing

Client-Publishing Log, Client-PackageConfig Log, or
  FileSystemmetadataLibrary Log

08

Client Common

Admin and Operational Logs

09

Policy

PolicyLibrary Log

0A

Virtualization Subsystem

May need to diagnose using the individual virtual subsystem debug logs.

0B

Subsystem Controller

Client SubsystemController Log

0C

Streaming Manager

Any of the five streaming debug logs

0E

Client Host

 

0F

Client Configuration

Registry/PowerShell

10

Scripting

Client Scripting Log

11

Client User Interface

Client-StreamingUX Log

12

Sequencer

Only on Sequencer

13

Reporting

Client Reporting Log

14

Manifest

ManifestLibrary Log

 

 

 

 

Then the last 8 digits will usually just be a standard Windows HRESULT code. In the example above, I know the issue is somewhere in the virtualization manager and the last eight digits are 0x0000001B. The HRESULT alone does not really lead me anywhere so I would likely need to dive further into the Client-VirtualizationManager debug log.

Sometimes, you will get really lucky. For example, if the error is 0xFC03E0480070003. Well, again we know it is an issue with the virtualization manager but the HRESULT 0x80070003 is well-known – ERROR_PATH_NOT_FOUND. You know where I would then go next – Process Monitor of course!

         
 Update 12/6/2014: The App-V 5 logs have been consolidated and are organized differently as of App-V 5 SP3 – but the event and event formats are still the same. Please read more about it here: http://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_event_logs_moved