Partager via

App-V 5: Further Dissection of the App-V Error Code Format

  • Article

I recently just returned from the Microsoft Global MVP Summit where I got to spend some time with the App-V MVPs. We received a lot of good feedback and I got to see some great presentations (as well as do a little bloviating of my own.) I received specific feedback encouraging me to write more App-V troubleshooting blog posts. I also got thrown for a temporary curve where I was asked what was the “20” component field of an App-V error message and why did I not include it when i was discussing this in my blog on dissection of App-V error codes. For example, what is the difference between hypothetical error code 0x3E500D04-80070005 and error code 0x3E500D20-80070005?

So in my recent said blog in question on App-V operational troubleshooting (https://blogs.technet.com/b/gladiatormsft/archive/2013/11/13/app-v-on-operational-troubleshooting-of-the-v5-client.aspx) I discussed the component mappings. What I did not point out was the fact that the upper three bits in that field also bear some significance.

So, the App-V 5 error return code format is similar to the Softgrid and App-V 4 error code format in that it has build-specific sections. For App-V 5, once a return code is in hex format, you can ignore the first six hex digits as it relates specifically to the source file and build number. The most important digits to look at are the last ten digits. What I neglected to point out in that blog post was the upper three bit values of the component field in the error code.

If the module field is greater than the numbers mentioned in the previous blog, you will need to further dissect the bits in that field.

  • 1st bit – This bit determines whether or not the return code is a success code or an error code. This is important because if you ever notice an error with the format xxxxxx8x-xxxxxxxx then you know it is actually a success code.
  • 2nd bit – This bit determines whether or not an event has been logged or not. If the bit is 1, an error has been logged.
  • 3rd bit – If this bit is flipped, it is a Windows code and not and App-V specific code.

Ultimately, these are revealed in hex as:

  • 8x-xxxxxxxx – You can ignore this message as this is a success code.
  • 4x-xxxxxxxx – The return code that has been logged as an event.
  • 2x-xxxxxxxx – This is actually a Windows error code and not an App-V specific event.

So, with this knowledge, let’s look at the following error:

0x00001525-00000057

So we know the first six digits is build-specific so we only need to look at the last 10 digits. When we convert the "25" field from hex to binary we get:

00100101

This tell us that the 3rd field is flipped to 1 so the error is a Windows error and not an App-V specific error. The remainder in the last five bit field is 05 in hex which means it was logged by the Shared Components module. Using the ERR utility or even “NET HELPMSG” you can resolve the 57.

So, to reinforce, let's look at another error:

0x45500D27-80072EE7

Again, if we focus on the 27 hex field, converting it to binary yields:

00100111

So again, we see this is a windows error. The last three bits convert to 07 hex which denotes the publishing agent. The last 8 digits translates to the HRESULT: ERROR_INTERNET_NAME_NOT_RESOLVED

Comments

  • Anonymous
    June 30, 2015
    ~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d like
  • Anonymous
    June 30, 2015
    ~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d like