I'm working on a 32 bit application which sometimes causes a certain 64 bit Windows 7 machine to crash. I've generated a dump file of the crash using the ProcDump utility from Sysinternals. (I used the command "procdump -ma -h MyApplication.exe".) Now, when I open the dump file with WinDbg, I get this error:
"Failure when opening dump file 'MyDumpFile.dmp', HRESULT 0x80004005. It may be corrupt or in a format not understood by the debugger."
This happens both when running WinDbg X86 on a 32 bit Windows XP machine, and when running WinDbg AMD64 on a 64 bit Windows 7 machine. Can you explain this?
EDIT - additional info: When running dumpchk on the file, it says:
"Minidump does not have system info. Could not open dump file [MyDumpFile.dmp], HRESULT 0x80004005 'Unspecified error'".
Maybe the dump file is simply corrupt?
Seems that you does not use procdump correctly.
Can you try to use ADPlus (which is also in Debugging Tools for Windows) to capture crash dumps?
http://support.microsoft.com/kb/286350
Related
I have a PowerShell script that I wrap with NSIS script to create .exe
PS script writes value to HKEY_LOCAL_MACHINE\SOFTWARE\FolderName
However, I noticed that it is actually writing to HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\FolderName
I am on 64bit OS. The default Hive should be 64bit and I am not setting or redirecting the registry to 32bit hive.
Executeable from NSIS writes to 32bit Hive.
If I run PS script in ISE, it write to 64bit hive, as expceted.
So, I do not know why it is writing under WOW6432Node when wrapped in NSIS. Anything I need to look at?
If you're running the script of 64bit machine, this would work.
${If} ${RunningX64}
${DisableX64FSRedirection}
${EndIf}
# put your code here
${If} ${RunningX64}
${EnableX64FSRedirection}
${EndIf}
As per my knowledge, NSIS uses two Win32 APIs to execute processes ShellExecute and CreateProcess
If your Operating System is 64 bit then both of them can run 64 bit process (x64) from NSIS 32 bit process.
The issue what you have faced is because it might have invoked a 32 bit PS. So double check on that part.
I have windbg registered as postmortem debugge (via -I command-line switch) and all works fine for non-elevated applications. But if elevated applications crashes, windbg starts and displays "Could not attach to process. Access is denied" error. Is it possible to somehow configure windbg so it will work as postmortem debugger for elevated apps?
Since you mentioned that it's an x86 app on an x64 system, you need to set these regkeys in Wow6432Node:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug]
"UserDebuggerHotKey"=dword:00000000
"Debugger"="\"C:\\debuggers\\windbg.exe\" -p %ld -e %ld -g"
"Auto"="1"
Note that these are both string values (REG_SZ) and I'm assuming that the windbg.exe is installed in C:\debuggers. Change that as appropriate.
I downloaded symbols for windows2003 server from here http://msdn.microsoft.com/en-us/windows/hardware/gg463028
I did what is described here - http://blogs.msdn.com/b/johan/archive/2007/11/13/getting-started-with-windbg-part-i.aspx. But when I try to run !threadpool it says
0:024> !threadpool
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.
This occurs because you have a different minor version of .net on your computer than the server has. I don't mean .net 3.5 vs 4.0, I mean version a.b.c.d.dll vs e.f.g.h.dll.
You need to get a copy of c:\windows\microsoft.net\framework\v2.0.50727\mscordacwks.dll from the windows2003 server.
Then, follow the steps in this post: http://blogs.msdn.com/b/dougste/archive/2009/02/18/failed-to-load-data-access-dll-0x80004005-or-what-is-mscordacwks-dll.aspx.
Try this first:
!sym noisy
.symfix c:\mylocalsymcache
.cordll -ve -u -l
If that doesn't work, then you'll rename the mscordacwks.dll file, copy it to the symbol location specified on your machine, and try again.
Please do not overwrite the file on your computer with the one from the windows 2003 server. :)
I'm trying to write a perl script that determines which users are currently logged into Windows by using query.exe (c:\Windows\system32\query.exe). Perl is unable to access this file, unable to execute it, even unable to see that it exists, as I've found with the following code:
print `dir c:\\windows\\system32\\query*`;
This produces the following output:
07/13/2009 05:16 PM 1,363,456 Query.dll
1 File(s) 1,363,456 bytes
0 Dir(s) 183,987,658,752 bytes free
I've checked the user executing the script using perl's getlogin function, and it returns the name of a member of the local Administrators group (specifically, me). I've also tried adding read/execute permissions for "Everyone", but windows keeps giving me access denied errors when I try to modify this file's permissions. Finally, I've tried running perl.exe as an administrator but that doesn't fix the problem either.
Is this something I can solve by changing some settings in Windows? Do I need to add something to my perl script? Or is there just no way to grant perl access to some of these processes?
On my 64 bit machine I can find query.exe in Windows\System32 (the 64 bit system directory) but not in Windows\SysWOW64 (the 32 bit system directory).
I suspect that you are running 64 bit Windows and 32 bit Perl and so, under WOW64 emulation, the 32 bit Perl process redirects system32 to SysWOW64.
Since system32 should be in your path you ought to be able to execute it by executing query.exe without any path. If you absolutely have to refer to the 64 bit system folder then you can do so from a 32 bit process with C:\Windows\sysnative.
If my suspicions are correct I recommend you do some reading up on WOW64 because it can be pretty confusing until you get on top of it. On the other hand, if you already know all about it I apologise for being patronising.
I am using windbg 6.12.0002.633 X86 on Windows Vista to analyze memory dumps for memory leaks.
I'm trying to use the command ``dumpheap -statto determine the quantities of objects in the heap.
Unfortunately, I'm getting the error*** ERROR: Symbol file could not be found. Defaulted to export symbols for SLC.dll. I have activated!sym noisyto show where the error comes from and the file SLC.pdb is just not available on the symbol server.
I have googled the file but haven't found such a downloadable file.
The last line in the log output says:Couldn't resolve error at "mpheap -stat"`.
I can't proceed debugging because I'm getting this error permanently.
Does anyone know where I can get a SLC.pdb file or another way to workaround this problem?
Writing
dumpheap -stat
Will result in
Couldn't resolve error at 'mpheap -stat'
However, this will work:
!dumpheap -stat
Note the exclamation mark !
Your error messages seems a little incomplete. The !dumpheap command is part of the SOS extension used to debug managed .NET code under WinDbg. Is that what you're trying to do? You should be able to use the command even without correct PDB files for all modules.
How did you load SOS? Can you use any other SOS commands?