Where is the list of stowed exception error codes ? RRS feed

  • Question

  • When a stowed exception is reported in the Health section of the dashboard there is an associated hex number - being the reason code

    Where are the list of reason codes to explaination of those codes ?

    E.g .






    The stack traces are quite frankly next to useless as they continue to simply show a hex offset into app code with no clue as to what function they may be interacting with - and yes we upload the symbol files...

    Wednesday, December 6, 2017 11:07 AM

All replies

  • Those look like COM error codes. If so then you can use FormatMessage as in Looking Up Text for Error Code Numbers. Note that most Windows API functions that process text have two versions, one with an "A" suffice for ANSI and another with a "W" suffix for Unicode. APIs present on all Windows 10 devices (grouped by module) - UWP app developer | Microsoft Docs says they are supported by UWP but you probably don't want the "A" version. Also see c# - FormatMessage not allowed? - Stack Overflow. Try searching for samples and if you need help then ask for clarification.

    Update: That first link for looking up errors is not relevant. See Retrieving the Last-Error Code (Windows) instead.

    Sam Hobbs

    Wednesday, December 6, 2017 6:04 PM
  • Actually the Looking Up Text for Error Code Numbers page says that the FormatMessage function gets its data from lmerr.h.

    winerror.h is another header; I think it used to be the one that the FormatMessage function used in the past.

    Another way to convert error codes to messages is the Error Lookup tool in Visual Studio.

    The question implies that the error codes are the result of a program that bbjbbj wrote; if not then the question is off-topic for the MSDN forums. The program can and should do the lookup. If that is not the best for whatever the question is for then I apologize.

    As for MFerror.h, that is for MediaFoundation events. See How to get text corresponding to Windows Media error codes? for how to use FormatMessage for Windows Media error codes. I assume that there are corresponding DLLs for other portions of the Windows SDK.

    Sam Hobbs

    Wednesday, December 6, 2017 8:39 PM
  • lmerr.h is not for HRESULT error codes. (its for network error definitions)

    I was too hasty in my initial reply. I did not find the correct page for an example so you are correct that the page I provided initially is inappropriate. See Retrieving the Last-Error Code for the correct page.  However HRESULT does not refer to the source of the error, it only refers to the format so HRESULT is not limited to network errors.

    and the sample onn the page you mentioned uses hModule = NULL = Default  to System source. That are the Errors returned by GetLastError;

    but "STOWED_EXCEPTION_INFORMATION_V2 structure" uses "ResultCode" of type "HRESULT"  (see Common HRESULT Values)

    Look at GetLastError; it says how to convert a system error into an HRESULT value. Many of the errors that FormatMessage processes when the FORMAT_MESSAGE_FROM_SYSTEM flag is used are HRESULT values.

    Note that hModule (lpSource) is ignored if neither the FORMAT_MESSAGE_FROM_HMODULE flag nor the FORMAT_MESSAGE_FROM_STRING flag is used.

    FormatMessage sets return values of GetLastError as text message. You need "FORMAT_MESSAGE_FROM_HMODULE" in flags and in the [..]lpSource parameter (..) a module handle containing the message-table resource(s) to search. If this lpSource handle is NULL, the current process's application image file will be searched.[..] If the module has no message table resource, the function fails with ERROR_RESOURCE_TYPE_NOT_FOUND[..]. FormatMessage

    Look again; lpSource is irrelevant unless one of the relevant flags are used. For errors retuned by GetLastError the FORMAT_MESSAGE_FROM_SYSTEM flag is used and the lpSource is irrelevant.

    So you deserve credit for discovering that the page I showed initially is for network errors and not relevant here but otherwise it would help for you to actually use this stuff so you are more familiar with how it all works together. I have used GetLastError and FormatMessage but it has been a few years since I did.

    Sam Hobbs

    Wednesday, December 6, 2017 10:53 PM
  • Well duh,

    Guess what, we tried searching in lots of places, reading docs/guides etc for several hours to no avail, hence resorted to asking on a forum.

    The above appears to pre-suppose the errors are being generated from known sources (functions and/or areas of functionality) within apps, that we can therefore trap them + convert them into more meaningful statements.

    We cant reproduce any of the Dev Centre reported crashes here so have little clues of where they might originate from other than the printed text such as 'stowed_exception_803f6107....' 

    Later replies appear to be more helpful.
    Thursday, December 7, 2017 8:03 AM
  • To clarify, the error codes are listed in the Health section of the DevCentre app - for apps weve written. These apps are then running on customer computers. 

    We cant reproduce the errors here on the PCs/phones we have currenly so have little clue as to where to put any 'lookup' code to text conversion.

    Thursday, December 7, 2017 8:11 AM
  • Thanks, this is exactly the bit we are missing

    Didnt think to look in the Win 7/8 forums as weve only produced UWP apps.

    Thursday, December 7, 2017 8:12 AM
  • Later replies appear to be more helpful.

    Quite often questions can provide more information and when they can, the more information there is, the more helpful the replies are. I do realize that sometimes too much information can also be a problem because sometimes people go in a direction that is not relevant. But notice that the original post does not say that the errors are not "being generated from known sources" or anything like that. The original question says "a hex offset into app code" and it is likely there is a way to use that to determine the location in your source code.

    Sam Hobbs

    Thursday, December 7, 2017 8:22 AM
  • Fair point, however we thought our original question was pretty clear + didnt really need any more info.

    We (perhaps naively) thought that whoever has defined the exception error codes might have bothered to actually document them in some manner - with the outside possibility they may have been centralized. It appears the 'documentation' is the header files.

    Indeed a hex offset can theoretically determine where in app code you have reached but quite frankly the days of having to know what address translation may or may not be happening on a particular platform + whether that gets moved every time you run an app are surely long gone. UWP apps are also built for 3 different processor architectures etc

    Thursday, December 7, 2017 8:58 AM
  • It seems some error codes are defined in header files

    e.g. full search in C:\Program Files (x86)\Windows Kits\10\Include\10.0.15063.0\um

    will reveal e.g. #define MF_E_UNSUPPORTED_SCHEME          _HRESULT_TYPEDEF_(0xC00D36C3L)

    However it seems other error codes are not defined in header files, e.g. a (Dev Studio) search for 803f6107 does not return any results - so not clear how/where any more info on this (+similar non defined) error numbers is supposed to be determined...

    Thursday, December 7, 2017 9:45 AM
  • I did indicate previously that winerr.h is useful but I did not make that clear enough.

    As internal access 54 indicated, the facility for that error code is 03f; decimal 63. Look at winerr.h; it has:


    So the error is a store error. Something else you can do is to search for the error; nearly always that is useful. If you do:


    Then you will definitely get results. The important one is In-app purchases and trials - UWP app developer | Microsoft Docs but you should look at the other results too.

    Sam Hobbs

    Thursday, December 7, 2017 8:19 PM
  • "The stack traces are not useless if you understand assembly"

    In theory we agree, in practice its massively more tricky - e.g. the info is from a release build, not a debug build (VStudio can cope), the binary is from a very specific version of source code (version control fixes that), its the machine code for one of 3 different processors (we only know the customers PC model), it typically assumes we can re-create the binary that MS cause customers to download from the store - which we probably cant as it has store specific signing going on which may/maynot move code around etc.... Even if we download the store binary run it, and attach via VS there is no guarantee we doing that on same processor variant, almost certainly different versions of Windows will apply different translations as they fix bugs ad-infinitum.

    So in all practical terms knowing the EIP is next to useless. (And doubly frustrating when the symbol tables are uploaded as part of the app submission)

    "write log files and use try-catch"

    Well yes, but try-catch assumes you know which code is likely to be generating the exception - so you know where to put it - and more fundamentally exactly what the exceptions mean as to whether its possible for the app to continue + work sensibly or whether they are fatal issues.

    So for 0x‭803F6107‬

    The only info we had previously was that it happens somewhere during app start up - very occasionally - perhaps 1 in 1000 users devices. App start up touches practically every external library/system type functionality.

    With everyones help (thankyou for that) it turns out this is something to do with the LicenceInformation class. The only functions we happen to use at start up are testing to see if a licence is active or not. The class documentation does not mention (anywhere that weve seen) simply trying to see if a licence is active or not can generate an exception. (As a double whammy on this one, you are forced to use different classes in debug+release builds - but thats a different issue).

    In this specific instance + as far as our apps are concerned we dont care if the 'IsActive' returns true or false - we deal with that. So an exception should not be fatal - as in terminate the app.

    So we go full circle.

    Had the exception been reasonably documented (somewhere we could locate before now)  or indeed it mentioned in the class docs that a superficially simple function could raise an exception in the first place we might have stood a chance of figuring out where to look for the issues.

    Thanks for your help in this.

    On a side note, is there any reasonable way of injecting exceptions into a system in some controlled fashion so code can be tested/debugged reproducibly? - many/many yrs ago we could do this on 16-bit systems.

    Friday, December 8, 2017 9:06 AM
  • The article about In-app purchases and trials says that 0x803F6107 is the result of not doing something. You say you don't do much with the LicenceInformation class so it might be possible that there are circumstances where "the Store doesn't have any knowledge about the app" and thereby causing a 0x803F6107.

    A StackOverflow response says that the problem was not a Package.StoreAssociation.xml and a StoreKey.pfx file in the project directory. That question I think says the exception occurs when checking the license.

    Sam Hobbs

    Friday, December 8, 2017 7:14 PM
  • These exceptions are happening in about 0.01% of customers computers, not our dev environment - so the xml/pfx stackoverflow response would not apply. As far as we can tell the functionality works on the remaining 99.99% of customer computers (and ours).

    Given the info we can only guess that there is some Store related issue on customer machines - maybe no connectivity (unlikely because we tested for that), store corrupt, or something else. Whether its fatal or not still remains a bit of a mystery, perhaps it all depends in the context the functions are called. Either way now we know approx where the excpetion is coming from we can add some code to catch it. Problem then becomes testing it - hence question on injecting exceptions....

    Saturday, December 9, 2017 2:44 PM
  • injecting = some way of telling (non app) code to fail + pretend there is an error... usually one thats very hard to create otherwise

    So e.g. if the Windows Store can report 'Store is corrupt' when you attempt to ask for something - rather than having to actually corrupt the Windows Store on a dev machine to force the error you would inject/force/lodge the error somewhere in the system + it would be picked up by code + thus an exception be generated.

    Were using CX/C++ - setting the exception handler is catching the exception - we effectively want to be able to raise the exception, but from within code we only have an API for. 

    Perhaps the nearest thing is to simply to raise an exception inline + directly after a function call which is probably close enough to one being raised somewhere within that function call to at least be able to manually step though the error/cleanup branch of code. (Doing this is subtly different but probably not sufficiently different to matter)

    • Edited by bbjbbj Saturday, December 9, 2017 3:34 PM
    Saturday, December 9, 2017 2:59 PM
  • We have a free to download app containing ads with a single IAP to remove the adverts.

    The window store has a record of that IAP in the form of a ProductLicence. Prior to a user purchaing the IAP item the ProductLicence reports IsActive as false.

    When a user purchases the IAP the ProductLicence for the IAP will return IsActive as true. 

    When our apps start up they may or may not have been purchased. We ask the store for the licence info for the IAP. If it reports no such thing exists or IsActive = false the app can continue - but display adverts. If it exists + IsActive reports TRUE then the store believes the user has purchased the app (regardless of whether our internal info says otherwise) so we should hide/remove adverts from display.

    Generating an exception if there is an issue accessing the store licening info may be right it may be wrong, depending on individual scenarios. In our scenario the product licence not existing e.g. due to corrupt store info is not a fatal issue. For others it may be. Either way, surely if a function is going to raise an exception at least it should be mentioned + the error codes listed to give developers half a chance of figuring out whats going on.

    Saturday, December 9, 2017 3:23 PM
  • Unfortunately there does not seem to be any pattern as to what version of windows is running. Yes weve tried quite a lot of different ways to test/reproduce a number of different exceptions that customers occasionally get - but without having a reasonable idea of where to look (hence wanting to know what the exception codes might mean) its pretty tricky to know what bit of system code to try and focus on.

    In the specific case of 0x‭803F6107: we have an outstanding support request with Microsoft (from May 2017 + still being worked on really hard by MS support apparently) yet they dont even seem to be able to identify it as a store related issue.

    Indeed we can now 'catch' this exception + go from there.

    THanks for assistance with this one.

    Sunday, December 10, 2017 9:23 AM