I'm trying to debug a 32 bit process dump from a process that ran on an x64 machine. I'm running an x86 version of windbg on my x64 laptop. I've followed the recommendations here, but I'm still getting this:
0:000> .cordll -ve -u -l
CLR DLL status: No load attempts
0:000> !clrstack
CLRDLL: C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscordacwks.dll:4.0.30319.17020 f:8
doesn't match desired version 4.0.30319.237 f:8
CLRDLL: Loaded DLL c:\symbols\public\mscordacwks_x86_x86_4.0.30319.237.dll\4DD234A8670000\mscordacwks_x86_x86_4.0.30319.237.dll
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 clr.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 clr.dll as well.
As far as I can determine, mscordacwks_x86_x86_4.0.30319.237.dll is successfully loaded, but I still get the error. What am I missing?
I resolved the issue by using ProcDump to get 32bit dump of the 32bit process that was running on a 64bit machine. I can successfully examine that using 32bit windbg. There are more details in this blog post.
It looks like you have a 32-bit dump file - otherwise the error would look like
CLR DLL status: ERROR: Unable to load DLL mscordacwks_AMD64_x86_2.0.50727.3053.dll, Win32 error 0n87
At least that's according to the blog post “Failed to load data access DLL, 0x80004005” – OR – What is mscordacwks.dll? on the Notes from a dark corner blog.
Note the mix of AMD64_x86 vs the x86_x86 in your error message.
For me, it's always because I don't have the correct version of mscordacwks. It's also possible windbg can't find it. See my answer to Problem debugging hang-dump in windbg for one method I've used to find/extract the correct version from security patches. To get windbg to load it, I set set the image path for windbg to point to the directory I've stored it in.
Related
Visual Studio 2019 Professional, retargeted qt project for qt 5.12.2 (Qt\5.12.2\msvc2017_64).
Trying to connect to a MySQL DB, although the files
qsqlmysqld.dll and
libmysql.dll
get loaded the output I get is
QSqlDatabase: QMYSQL3 driver not loaded QSqlDatabase: available
drivers: QSQLITE QMYSQL QMYSQL3 QODBC QODBC3 QPSQL QPSQL7
Could not connect
What could be wrong this time?
edit: for clarification purposes that's the output I get
'Current Project' (Win32): Loaded 'C:\Qt\5.12.2\msvc2017_64\plugins\sqldrivers\qsqlmysqld.dll'.
'Current Project' (Win32): Loaded '....\libmysql.dll'.
So it's true that it doesn't load the libmysqld.dll library.
Something else that is unclear to me is the Win32 in the parentheses, as I have x64 selected.
I have tried both x86 and x64 versions of libmysql.dll but it didn't work.
Furthermore running dumpbin to identify library dependencies it seems that everything is there
Finally I found a solution but with some compromises.
First and foremost we cannot debug, oracle won't allow. So we need to make sure that it's a release configuration.
In order for the application to run we need to copy within the folder where the executable is the x64 bit version of libmysql.dll. But this is not enough
This dll has some dependencies that seem to be different between versions, so in order to find them I had to run the dumpbin command with the /dependents flag. For my case and version the mysql server included dlls where
libcrypto-1_1-x64.dll
and
libssl-1_1-x64.dll
After that I could successfully make queries to the instance of the Mysql Server
In-House developed .exe file is failing in container, it prints no error, and just returns the exit code -1073741515. The exe seems to be running fine on other machines. I understand this error code means it's missing a DLL File or Library but I don't which one.
It's a windowsservercore based container. Running no other application except this .exe, and running it on Command Prompt, although Powershell also return same exit code.
I took a dump of it using dumpbin tool (which comes with Visual Studio), to check which DLL files it uses, and my container is also having all those DLLs
I tried Dr. Memory tools like drmemory.exe and it says the WARNING: libraries needed by the application are missing. Check that it runs successfully on its own and check that all needed libraries are in its directory or on the PATH.
I am running out of options to troubleshoot. How can I find what is causing this .exe to fail or any missing dependency?
I am trying to set up a web api using ASP.NET Core on OS X. I have set up my environment correctly (I think) and I'm able to build and run my application using dotnet build from the terminal, and I'm able to start debugging from Visual Studio Code with breakpoints working as expected. My problem is that I receive an error when trying to query my Sqlite database using EF core. EF core is not really important here, because when I am debugging and trying to find out what the error is, I don't get any stack trace. When I step over the failing code the debug console prints:
Exception thrown: 'System.InvalidOperationException' in Microsoft.EntityFrameworkCore.dll
Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/1.0.0/System.Diagnostics.StackTrace.dll'. Cannot find or open the symbol file.
Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/1.0.0/System.Reflection.Metadata.dll'. Cannot find or open the symbol file.
Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/1.0.0/System.IO.MemoryMappedFiles.dll'. Cannot find or open the symbol file.
Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/1.0.0/System.IO.UnmanagedMemoryStream.dll'. Cannot find or open the symbol file.
A lot of these Cannot find or open the symbol file. are printed at startup as well. I have checked that the files are at the location specified, and that there shouldn't be any read access problem (having started vs code with sudo code . and even done a sudo chmod 777 * in the folder in question).
So, any ideas why the symbols aren't loaded?
Ran into the same issues running VS Code on a Windows 10 VM.
The resolution I found was to add a "debugType": "portable" setting to the buildOptions section of my project.json file.
Mine looks like this:
"buildOptions": {
"emitEntryPoint": true,
"preserveCompilationContext": true,
"debugType": "portable"
}
Debugging in VS Code isn't that bad actually.
I think you have confused what VSCode is saying it cannot load. It isn't saying that it can't load the DLL. 'Symbol' files have a .PDB extension. In order to debug an error generated by a DLL, a debugger needs the corresponding symbol file, so changing the permissions on the DLL won't make the error go away if the PDB file is not there.
I've just started using VSCode on a Mac and from what I can see, you don't get the PDB files if you install dotnet core with Homebrew (which is what they recommend) and I see similar messages when I startup the debugger. That doesn't stop me from debugging my own code because there is a PDB file generated with my DLL. It would only cause a problem if you needed to debug something going wrong inside dotnet core itself.
I tried to generate a 64-bit FireBreath MSI installer using heat.exe but got the following output:
heat.exe : warning HEAT1108 : The command line switch 't:' is deprecated.
Please use 't' instead.
heat.exe : warning HEAT5150 : Could not harvest data from a file that was
expected to be a SelfReg DLL:
C:\Users\firebreath-master\buildPlugin\bin\Release\myPlugin64.dll.
If this file does not support SelfReg you can ignore this warning.
Otherwise, this error detail may be helpful to diagnose the failure:
Unable to load file:
C:\Users\firebreath- master\buildPlugin\bin\Release\myPlugin64.dll, error: 193
In order to generate the 64-bit .msi I copied the MyPlugin_auto.wxs that was generated from the 32-bit .dll, and build again using the 64-bit .dll and the MyPlugin_auto.wxs that was copied previously. 64-bit msi was generated without errors, I installed it, test it and it works, but I would like to ask if it is a better way to get over the heat.exe bug.
Heat is telling you that it saw a Dll with the DllRegisterServer() function exposed and that it failed to harvest any COM information. This typically means that the DLL is missing dependencies and that DllRegisterServer() failed to run correctly during the harvesting.
I'd take a look at the DLL using Depends and look for missing dependencies. Put those DLL's into the directory and try harvesting again.
I'm trying to debug a driver issue on a WinXP SP3 system. However, when I connect to the debugger I get:
* ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrpamp.exe
My host machine is WinXP x64 SP2. My debugger version is 6.11.0001.404 (AMD64). The target is WinXP x86 SP3. When I run 'vertarget' I get:
Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp3_gdr.100427-1636
I used '!sym noisy' to get full symbol loading output. When I try to reload the nt module (the one that didn't load correctly) it lists all the places it looks for the pdb file. For the line where the correct file is (I installed the XP SP3 free symbols) it says:
DBGHELP: e:\symbols\wxp_sp3_x86_fre\exe\ntkrpamp.pdb - mismatched pdb
This is all it tells me. It doesn't say why it's mismatched. Am I missing something here? Thanks in advance.
NOTE: Connecting to Microsoft's symbol server is not an option. The host machine is on an intranet and cannot be connected to the outside world.
EDIT: I was able to fix the problem by reinstalling the target machine. I know the target had some Windows updates installed and I suspect one of these made the symbols for ntkrpamp.exe go out-of-date.
The debugger uses timestamps and a checksum to validate the symbols. If you are sure you have the right symbols then just use .reload /fi NT to force loading the PDB you have in the symbol path.
If you do not have access to the internet form the machine being debugged, you can always copy binary to a flash drive, take it to a machine that does have access to the Internet and use kd -z ntkrpamp.exe to debug the binary as a dump file. This will allow you to use Microsoft's symbol server. You can then copy the PDB from the local path to your intranet environment via a flash drive.