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 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).
NI=Native Image. In other words, NGEN'd images as the comments above indicate.
Related
I am working with a multi-threaded application, which should reguarly be launching a thread, asking about the status of some "cars".
As one of the threads is still working (visible in Process Explorer and in the "Threads" part of the memory dump), I believe I'm dealing here with a deadlock.
In order to investigate this, I have downloaded dotnet-dump and I launched the following command in commandline:
Prompt> dotnet-dump.exe analyze "Dumpfile.DMP"
Once inside this dotnet-dump session, I have tried launching clrstack -all, as indicated in this URL.
This, however, seems not to be working:
> clrstack -all
Failed to load data access module, 0x80004002
Can not load or initialize mscordacwks.dll. The target runtime may not be initialized.
For more information see https://go.microsoft.com/fwlink/?linkid=2135652
> setsymbolserver -ms
Added Microsoft public symbol server
> clrstack -all
Failed to load data access module, 0x80004002
Can not load or initialize mscordacwks.dll. The target runtime may not be initialized.
For more information see https://go.microsoft.com/fwlink/?linkid=2135652
I have followed the advise in that webpage but no success.
In top of this, I have different "mscordacwks.dll" files on my PC. How can I know which one to take?
Or even better, is there an easier way to investigate a dotNet memory dump for deadlock analysis?
Edit: For your understanding: I have the application open in Visual Studio, but I know from previous experience that tools like "Windbg" have commands like !locks which can be used for (dead)lock analysis. While searching on how to investigate (dead)locks in .Net, I stumbled upon the dotnet-dump tool.
I have downloaded ProcDump from Windows Sysinternals site. https://learn.microsoft.com/en-us/sysinternals/downloads/procdump
I have used below command to initiate dump collection.
procdump -ma <process_name>
Here is the command line output
[08:17:43] Dump 1 initiated:
E:\SSDT\Procdump\WindowsService.exe_180926_081743.dmp
[08:17:47] Dump 1 writing: Estimated dump file size is 2309 MB.
[08:17:59] Dump 1 complete: 2310 MB written in 16.5 seconds
[08:18:00] Dump count reached.
Now, I am trying to import it in JetBrains dotMemory but unfortunately I am getting below error prompt.
dotMemory
Unable to import the dump: 64-bit dumps of 32-bit processes are currently not >supported. Please use a 32-bit tool to take a dump. For example, >%WinDir%\SysWOW64\taskmgr.exe is a 32-bit version of Task Manager.
What is meaning of 64-bit dumps of 32-bit processes? I have tried to create dump from both the EXE's from ProcDump, But I get the same message prompt.
Some of the dump-taking tools (TaskManager for instance) write dumps in a 64-bit format even for 32-bit applications.
ClrMd (which is currently used in background for dump processing in dotMemory) doesn't handle this situation well (addressing issues).
So there is an additional check in dotMemory which detects if this is the case on early stages and shows the message.
Normally Procdump is known for producing proper dumps independently from the procdump bitness.
But it looks like in your scenario something is different.
Could you please upload dumps produced by both procdump.exe and procdump64.exe to https://uploads.services.jetbrains.com/ and mention the names?
This will help the team to investigate the case.
As the documentation says, if you start %WinDir%\SysWOW64\taskmgr.exe (32bit version of task manager) you can right click on your process then create the dump (for your 32bit application
I'm exploring the feasibility of running a C# Kinect Visual Gesture Program (something like Continuous Gesture Basics project https://github.com/angelaHillier/ContinuousGestureBasics-WPF) inside of a Docker for Windows container.
Is this even theoretically possible (run C# Kinect in a Docker for Windows container?)
If the answer to 1 is yes, here are some extra details:
I'm using the microsoft/dotnet-framework:4.7 image as a basis and my initial Dockerfile looks like this:
FROM microsoft/dotnet-framework:4.7
ADD . /home/gesture
WORKDIR /home/gesture
Build the image:
$ docker build -t kinect .
Turn on container:
$ docker run -dit --name kinectContainer kinect
Attach to a powershell session to monkey around:
$ docker exec -it kinectContainer powershell
When I attempt to run my gesture application from the Docker container I get the following error (which is expected since no Kinect SDK was installed in the container):
Unhandled Exception: System.BadImageFormatException: Could not load file or assembly 'Microsoft.Kinect, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependenc
ies. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058) ---> System.BadImageFormatExcep
tion: Cannot load a reference assembly for execution. erable program. Check the spelling of the name, or if a path was included, verify that the path
--- End of inner exception stack trace ---
at GestureDetector.GestureDetectorApp..ctor()
At this point, the big question is how to install the Kinect v2 SDK [KinectSDK-v2.0_1409-Setup.exe] or the Kinect v2 runtime [KinectRuntime-v2.0_1409-Setup.exe] in the container.
The installers have a EULA and according to some clever University of Wisconsin folks, there is a technique to to extract installers using Wix's dark.exe decompiler(https://social.msdn.microsoft.com/Forums/en-US/a5b04520-e437-48e3-ba22-e2cdb46b4d62/silent-install-installation-instructions?forum=kinectsdk)
ex.
$ & 'C:\Program Files (x86)\WiX Toolset v3.11\bin\dark.exe' C:\installerwork\KinectRuntime-v2.0_1409-Setup.exe -x c:\installerwork\kinect_sdk_installersfiles
The issue I ran into when I got to the underlying msi files is there is no option to run them silently using msiexec.
I've figured out that the runtime installer (Runtime installer (KinectRuntime-x64.msi) extracted from the Kinect v2 SDK) makes at least the following changes in the filesystem:
Creates a folder "Kinect" in C:\Windows\System32 and adds 3 files to System 32:
k4wcll.dll
kinect20.dll
microsoft._kinect.dll
The last three files in System32 should be the 64-bit versions (the installer appears to have x86 and x64 versions of those 3)
Replicating those changes by hand does not lead to success on the host machine let alone in the container.
It's currently unclear what other registry/system changes are occurring with the installer (and whether or not that would get us over the goal line in the Docker container)
Any ideas about how to proceed from here?
In short no. docker on windows does not have the ability to hardware tunnel/map. on Linux, it does via the --device= option
As #VonC has stated you will need to use a Windows VM this could be Hyper-V or you can use Virtual Box then you can provide the Kinect Hardware via the Tunneling method (add/connect device), without this there would be no way for your container be that VM or not to access the hardware of the host machine with windows.
Another approach would be to try and install Kinetic in a Windows server VM, and detect the exact changes brought by said installation.
See for instance "How can I find out what modifications a program’s installer makes?" and a tool like ZSoft Uninstaller 2.5.
Once you have determined exactly what files/registry/variables are impacted by the installation process, you can replicate that in a Dockerfile.
I need to do crash dump analysis for a .net exe using Windbg.
I read multiple blogs on MSDN to setup my Windbg but looks like it still has issues loading 'mscordacwks.dll'.
Upon running this command i get this:
Failed to load data access DLL, 0x80004005 Verify that 1) you have a
recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of mscorwks.dll is
in the version directory
3) or, if you are debugging a dump file, verify that the file
mscordacwks_.dll is on your symbol path.
4) you are debugging on the same architecture as the dump file.
For example, an IA64 dump file must be debugged on an IA64
machine.
You can also run the debugger command .cordll to control the
debugger's load of mscordacwks.dll. .cordll -ve -u -l will do a
verbose reload. If that succeeds, the SOS command should work on
retry.
If you are debugging a minidump, you need to make sure that your
executable path is pointing to mscorwks.dll as well.
Here are quick details of my environment:
EXE is 32 -bit so using x86 debugger
In the following path: C:\Windows\Microsoft.NET\Framework\v2.0.50727 the two DLLs are located
:
->mscorwks.dll
->mscordacwks.dll file version: 2.0.50727.5485
Symbol path is : c:\debug\symbols
Debugging tools(i.e. Windbg installation) is located at: C:\Program Files (x86)\Windows Kits\10\Debuggers\x86
Copied mscorwks.dll and mscordacwks.dll in this path and renamed to(as per some blog on MSDN) :
-> mscordacwks_x86_x86_2.0.50727.5485
-> mscorwks_x86_x86_2.0.50727.5485
Not sure if these names are correct or not.
Still it never worked.
After doing a lot of search, I still couldn't get the solution for the question.
I have a mdmp file. The call stack shows it is using mscorlib.ni.dll. So to get the function information, I need to get its pdb file.
The version of mscorlib.ni.dll is 2.0.50727.3655.
I believe it comes from .Net Framework 3.5.
Since mscorlib.ni.dll is the native optimized dll which is generated by ngen.exe, so I need to use ngen.exe createpdb to generate pdf for this dll.
ngen.exe createpdb "C:\Windows\assembly\...\mscorlib.ni.dll" "C:\SymbolCache"
Here is the result:
I can't find ngen.exe in folder "C:\Windows\Microsoft.NET\Framework64\v3.5"
I could find ngen.exe in folder "C:\Windows\Microsoft.NET\Framework64\v2", but it does not have createpdb option.
I could find ngen.exe in folder "C:\Windows\Microsoft.NET\Framework64\v4.0.30319" and it does support createpdb option, but it reports error.
Microsoft (R) CLR Native Image Generator - Version 4.0.30319.18408
Copyright (c) Microsoft Corporation. All rights reserved. Invalid
header found in native image
'C:\Windows\assembly\NativeImages_v2.0.507
7_64\mscorlib\5cd1c2848ff40eb0a8c149706ee394fa\mscorlib.ni.dll'.
Unspecified error (Exception from HRESULT: 0x80004005 (E_FAIL))
So I have no idea how to get the pdb for this mscorlib.ni.dll of Net Framework 3.5.
Any idea?
I had the same error message until I realized I call ngen.exe from the Framework64 folder. Apparently, the mscorlib.ni.dll was not 64-bit.
So I used the 32-bit version of ngen.exe from the folder C:\Windows\Microsoft.NET\Framework\v4.0.30319 and it successfully produced the PDB.
However, the path to your mscorlib.ni.dll includes ...\NativeImages_v2.0.507 7_64\..., which indicates it is 64-bit, so this might be a different issue.
Like the answer from Monsignor, for me the solution was to match the bit-ness (64-bit or 32-bit). My minidump was 64-bit so I had to go to the Framework64 folder and run ngen from there and it was fine. I originally got the same ngen error as described here (Invalid header found in native image...E_FAIL) because I was in the Framework folder instead of the Framework64 folder (facepalm).
However, even though the ngen command worked...the pdb that was generated ultimately was still not accepted by VS 2013 as a matching symbol file, in my scenario.