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.
Related
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.
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.
My problem might seem specific, but in fact it is probably very general: How to publish a Console Application that uses 3rd party references?
I am using Visual Studio 2015 to make a Console Application called Gdx2PostgreSql programmed in Visual Basic. The application is reading data in a Gdx-file (output from a GAMS program, www.gams.com) and writing the data to a PostgreSql database. The interface to PostgreSql is handled by NpgSql, www.npgsql.org. NpgSql is referenced as
\\dtu-storage\hela\Documents\Visual Studio 2015\Projects\GDX to PostgreSQL 2\packages\Npgsql.3.1.7\lib\net451\Npgsql.dll
The program functions correctly when it is executed in Debug mode inside Visual Studio.
I have to be able to run the program from the command prompt in a CMD window. Moreover, I have to be able to run the program by spawning from a GAMS program using the GAMS syntax
Execute 'Gdx2PostgreSql "FileName.gdx" "CaseName"';
I have published the program and run the setup file installing the program. But when I run it in a CMD window I get the error:
'Gdx2PostgreSql' is not recognized as an internal or external command, operable program or batch file.
I get the same error message when spawning from my GAMS program.
Being rather desperate I have tried renaming the file setup.exe in the Publish-folder to Gdx2PostgreSql.exe. When I use this file I get:
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Npgsql, Version=3.1.7.0, Culture=neutral, PublicKeyToken=5d8b90d52f46fda7' or one of its dependencies. The system cannot find the file specified.
That is, NpgSql is not known to the program.
As I see it, I need to have one EXE-file that holds all what is needed - especially because my program should be able to run on other PCs, too.
Can anyone help me make my program Gdx2PostgreSql function?
Finally, I should mention that I have made other programs reading Gdx-files and using NggSql to write to PostgreSql. These programs function correctly, but they are Windows Forms Applications – and not Console Applications.
Console applications aren't really any different from winforms applications - you have to distribute the EXE along with any DLLs it depends on - in the same directory. As mentioned in the comment, after building your program you should be able to find everything you need under bin/Debug (or Release).
Regarding why your Gdx2PostgreSql isn't being found, that's likely a problem of path - try running your program with an absolute path, or cd'ing into bin/Debug (or Release) before executing it.
I want to load MSEC.dll in windbg Version 6.12.0002.633 X86.
when I use the command !load MSEC.dll
it says:
The call to LoadLibrary(MSEC.dll) failed, Win32 error 0n127
"The specified procedure could not be found."
Please check your debugger configuration and/or network access.
I changed the version to 6.11 and I also installed visual studio 12 run time with version 12 but it doesn't work!
Is there any way to handle this issue?
When we extract Bang Exploitable (!Exploitable) it creates 2 Folders:
x64
x86
Open the folder as per your Project Bit Size. Now inside that folder, you will get 2 another folders:
Release
Debug
Copy the files from release folder to the folder that contains the executable of windbg.
Sometimes you may also need to change the version of windbg for making it compatible with bang exploitable.
Download
http://download.microsoft.com/download/A/6/A/A6AC035D-DA3F-4F0C-ADA4-37C8E5D34E3D/setup/WinSDKDebuggingTools/dbg_x86.msi
I had the same issue (winxp sp3, windbg 6.12..., !exploitable 1.6). Installing CRT 11 runtime did not work for me. So, the only solution I've found is to use the older version of !exploitable (1.0.6), you can download it here: https://msecdbg.codeplex.com/releases/view/28935
I spent all morning trying to figure this out.
Codeplex was retired in 2021 and this assembly appears to be abandoned by MS so it's difficult to find information.
The site I'm linking to below indicates that you need the Visual C++ 2012 redistributable installed on the target machine to remove this issue.
The same site also statically linked the required files in the source code and rebuilt with VS2017. I downloaded the altered DLL and am now able to load msec.dll with the full path to the assembly in the command.
https://blog.didierstevens.com/2018/07/17/exploitable-crash-analyzer-statically-linked-crt/
0:025> !pe
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_<arch>_<arch>_<version>.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.
After corflags.exe /32bit+ xxxx.exe to run on a 64bit server 2003, the xxxx.exe usually crash. I got this dump, on the same machine, install windbg(x86), but I can't use SOS. I googled this issue, but can't find work answer. I use the same machine, why windbg can't find what it need?
The problem is that the correct version of mscordacwks.dll can't be located. The DLL acts as an abstraction layer between the runtime and SOS and thus it must correspond to the version of the runtime. There's an excellent write up of the problem and its solution here http://blogs.msdn.com/dougste/archive/2009/02/18/failed-to-load-data-access-dll-0x80004005-or-what-is-mscordacwks-dll.aspx
Make sure to follow the advice on renaming the DLL very carefully, cause if you get it wrong it doesn't work and the error messages are not very helpful imo.