I got a minidump from the Windows Store Apps submission process (sent by a reviewer) because of a crash in my app. I am having problems loading the symbols for my app, because the error occurs inside App.ni.exe
, a file which I don't know where comes from.
My app only has a App.exe
(and some DLLs), but the dump keeps referring to .ni.dll
and .ni.exe
. These files are nowhere to be found in my .appx
or .appxsym
files.
My app is built for each specific platform (x86, x64, and ARM). It is the x64 version that crashed in the stackdump.
My current attempts with windbg:
Symbol path:
Srv*C:\Users\Vegard\Appdata\local\temp\SymbolCache*http://msdl.microsoft.com/download/symbols`
Windbg attempt:
0:006> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
Unable to load image Newtonsoft.Json.ni.dll, Win32 error 0n2
*** WARNING: Unable to verify checksum for Newtonsoft.Json.ni.dll
*** ERROR: Module load completed but symbols could not be loaded for Newtonsoft.Json.ni.dll
Unable to load image App.ni.exe, Win32 error 0n2
*** WARNING: Unable to verify checksum for App.ni.exe
*** ERROR: Module load completed but symbols could not be loaded for App.ni.exe
Unable to load image mscorlib.ni.dll, Win32 error 0n2
*** WARNING: Unable to verify checksum for mscorlib.ni.dll
Update: Trying to ngen App.exe (running as admin) I get the following error:
> ngen.exe install App.exe
[snip]
This operation is only valid in the context of an app container.
(Exception from HRESULT: 0x8007109A)
What is an app container in this case? Where should I run it from?
Update: After a long while troubleshooting, and figuring out the root cause through other means, I have concluded that the minidump file I got was missing this information. No matter of coaxing could get the debugger to load the symbols for the files.
Take a look on the tool description Ngen.exe (Native Image Generator):
The Native Image Generator (Ngen.exe) is a tool that improves the performance of managed applications. Ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead of using the just-in-time (JIT) compiler to compile the original assembly.
Keep in mind this processor-specific machine code
.
If you need to debug minidump with NI images you need to get symbols (PDBs) for these images. The PDBs for managed DLL will not work, you need to generate Native PDB for NGEN'd image with NGEN tool, take a look on the article Creating NGEN PDBs for Profiling Reports. This article about how to get NGEN pdbs for Profiler Report, but for debugging it is the same.
As I said keep in mind that NGEN is a processor-specific machine code
, so to generate PDBs for them:
Since NGEN’d images are native, it’s important you use the copy of ngen.exe that matches the architecture of the application you are profiling (x86/x64/ARM). For example if the application is running 64 bit on Windows 8 RTM then you would need to reference the copy of ngen.exe in “C:\Windows\Microsoft.NET\Framework64\v4.0.30319”
UPDATE:
From the link above:
if you remote profiled a Windows Store App, you have to do this on the machine you were running the app on while you were profiling. It will not work if you do it on the machine you are viewing the report on
So it looks like you need to generate ngen modules / pdbs on the same machine where you got the minidump.
Windows has a Native Image Service, which generates ni images for Windows Store Applications after some time when you install it on your machine. You can try to use procmon.exe to find how Windows generate ngen modules for applications from Windows Store. (just use filter for Process Name with ngen.exe).
NI=Native Image. In other words, NGEN'd images as the comments above indicate.
User contributions licensed under CC BY-SA 3.0