What are .ni.dll and .ni.exe files in a minidump?

Question

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.

Jaguarundi

.ni files are NGEN'd files. – Anderaanderea

@leppie: Thank you for that, helped me get quite a bit. I have not been able to generate these files myself using ngen. Apparently it is "only valid in the context of an app container". How do I get around that? – Jaguarundi

You don't even need to use !analyze -v if this is a managed application. Why not load sos and see what was the exception that brought it down? – Aviv

@Lex Li: I know it is a StackOverflowException. However, I can't figure out where in my code this originates, as I cannot get the complete stack track without the symbols. – Jaguarundi

For .NET based application, sos provides !CLRStack. Even without symbols you can get the correct managed call stack of a thread and easily locate the culprit. – Aviv

By loading SOS.dll and running !CLRStack, I only get App_ni!<unknown method> for all calls into my app. That doesn't help much... – Jaguarundi

You may want to try !sosex.mk to see if you can get a better stack trace. – Accede

@SteveJohnson: With !sosex.mk, I only get addresses into my app, no method names. – Jaguarundi

Answer 1

Take a look at 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).

Brooklet

See update in question for what happens when I try to ngen the app. – Jaguarundi

@VegardLarsen it looks like NGEN tool does not allow you to generate NGEN images for modules and exe files from App Containers, it can be a security restriction. I will try to investigate more on this and let you know if I will find something. – Brooklet

btw, I had wrong link to article Creating NGEN PDBs for Profiling Reports, now it is fixed – Brooklet

@VegardLarsen I updated my answer with some more information. – Brooklet

Answer 2

NI=Native Image. In other words, NGEN'd images as the comments above indicate.

Accede