I'm trying to debug a 64bit .NET 4.5.2 application and am having trouble loading the sos extension. My normal deal is to open up the x64 WinDbg executable, type in .loadby sos clr and go on about my business. Today, when I type that into WinDbg, it just stares at me and does nothing. Using any extension from the library gives an error message of "No export found". I did this about a month ago on the same machine and it worked fine. My symbols are srv*https://msdl.microsoft.com/download/symbols, which is pretty standard fare.
I then tried to load SOS directly using .load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll (the file exists, btw), and it also does nothing.
I suspect my company has blocked something, but I have no idea what it is or where to start.
Related
The official way to do this appears to be to use WinDbg. That should be able to give me the information I need, very easily. However, I don't have WinDbg, and my attempts to install it have failed for no known reason. So, is there another way to find my bad line of code? Or, is there a way other than using Microsoft's Windows SDK installer to get WinDbg?
My DLL is an unmanaged DLL (no CLR) built using Visual Studio 2012.
Using WinDbg to debug a .NET dump, command !clrstack gets a warning:
*** WARNING: Unable to verify checksum for PresentationFramework.ni.dll.
I have set the symbol path to SRV*D:\MsSymbols*http://msdl.microsoft.com/download/symbols. How to solve this warning and how to load the matching SOS and CLR?
The *.ni.dll are native images, i.e. a .NET DLL that has been pre-compiled by ngen.exe for your PC. Since this was compiled on your machine, there won't be symbols for download from the Microsoft server. Nothing to worry about.
Regarding the version of SOS and MSCorDacWks, it depends a little bit.
a) you were loading a specific version using .load x:\path\to\sos.dll. In that case, try loading SOS with .loadby sos clr. If that works, you were lucky.
b) if you have loaded SOS with .loadby sos clr already, you have created the crash dump on a different machine. In that case you need get the exact version of SOS and MSCorDacWks. This can be achieved by
b.1) run .unload sos and !analyze -v. If often downloads a correct SOS version and stores it somewhere in the symbol path.
b.2) go to the machine and find the files manually
b.3) use MsCorDacWks Collector and run it on that machine. It will grab all available versions of SOS and MSCorDacWks. Disclaimer: I'm the author of that tool.
b.4) If the machine is no longer available, have a look at my SOS archive. You're unlucky this time, but there's at least a very close version 4.7.2116. Disclaimer: I'm the maintainer of that archive.
I have a simulink model (2016b with MC 2013 C/C++ and Mingw-64 compilers) that I'd like to generate a standalone executable for windows-64 bit.
I was able to run the grt executable but due to the fact that I need to read a mat file runtime as opposed to compile time, I am using rsim code generation for this purpose, however the executable that gets generated appears to need quite a bit of .dll, I provided the dll it was asking for however, the application still unable to run. This is the error that results
The application was unable to start correctly 0xc000007b. Click OK to
close the application
What am I missing ?
Your main program is compiled for x64 (64-bit) target, but the dll you provided is compiled for x86 (32-bit) target. Or vice versa.
If it is Mingw-64 stuff, you should be able to obtain all (or most) of them by using the official online installer. Link is here.
I have received a mini dump file from our network support team. They complain that one of our sites on the production node causes high cpu usage.
The Windows server is x64 but the IIS App Pool is running in 32-bit mode. The network/support guys have used the default task manager to create the dump file so I assume the dump file must be a 64-bit one.
I downloaded WinDbg x64. Then I tried to follow the instruction given in the link below to find which part of the code can be problematic:
site
Although the dump file and WinDbg both are 64-bit, when I run "lmvm clr"command, the debugger shows this line:
Image path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
If I run this command:
.loadby sos clr
and then !pe command, I get "no export !pe found" (this happens with any other command such as !CLRStack).
If I get the 64-bit version of mscordacwks.dll and sos.dll, and copy them into the symbol folder, the libraries will be loaded but upon running !pe command I will get "Failed to load data access DLL, 0x80004005 error message!
What I am doing wrong? I asked the network team to send me the .dll files (sos.dll and mscordacwks.dll), I copied them to the symbols folder but nothing changed.
p.s. I have read all the similar posts but none helped.
Open the dump in a 32-bit debugger and run !wow64exts.sw. You should now be able to load SOS and run commands, though not all commands will work. This will help, but still the best solution is to gather the dump with a 32-bit tool.
first things first:
It was working when I used it last time (which is about more than a month ago).
The Problem is, that no command which is from an extension is working, it seems like no extension is loaded.
Only the default commands do work (like version etc.)
The output of the command "Version" is:
Extension DLL chain:
dbghelp: image 6.2.9200.16384, API 6.1.6, built Sat Nov 20 12:57:48 2010
[path: C:\Windows\system32\dbghelp.dll]
ext: (Not loaded)
wow64exts: (Not loaded)
exts: (Not loaded)
uext: (Not loaded)
ntsdexts: (Not loaded)
It says that no extensions were loaded, but the folder winext does exist in my system32 folder (C:\Windows\System32\winext), where the extensions are located in (as far as I know).
Commands like !gle do not work :/
I really have no Idea what I can do, please help me :)
Does the DBGTOOLS definition in your IDA.CFG point to the x86 WinDBG installation directory?
The following comes from IDA Pro's help:
Windbg debugger plugin has the following configuration options:
- The Debugging Tools folder: This should be configured to point to the same
folder where Microsoft Debugging Tools are installed. The plugin will try to
guess where the tools are, but if it fails, a manual intervention will be
required. If this option is not set, then the plugin will try to use dbgeng.dll
from MS Windows system folder, while normal debug operations will work,
extensions will not.
This information indicates that if IDA Pro is using dbgeng.dll from the Windows system folder, the extensions command (like !gle) will not work.
If you have already setup the DBGTOOLS to point to your WinDbg (x86 version) directory correctly in your /cfg/ida.cfg but IDA Pro is still using dbgeng.dll from your Windows system folder, then probably your IDA context is not configured to analyze the IBM PC processor. This may happen when you launch IDA Pro and click the 'Go' button directly to work on your own and start the WinDbg debugger.
Check the DBGTOOLS in the ida.cfg, you will find it is wrapped by #ifdef __PC__ #endif.
The __PC__ will only gets defined by IDA Pro if you are analyzing a Windows EXE file for example. Give a try to launch the WinDbg from the IDA Pro menu after you have successfully disassembled a Windows EXE file and see what happens.
If this still hasn't been answered your problem is most likely that you didn't uncomment the DBG Tools line in the ida.cfg file.
I just fixed this myself. hope this helps.
Also the other guys are correct as well. make sure you are escaping with double back slashes "\\" and make sure you pointing to the (x86) directory.