Menu
I have a dump (created by SysInternal's procdump) and when I ask to view the call stack of a thread I get the error:
"WARNING: Unable to verify timestamp for mydll.dll"
I own the source code for mydll.dll and I have the PDB file for it, the call stack seems valid but I would like to know what can be the cause of the message. In the past I did not get that warning message.
Thank you.
879
I have to ask. Does the file timestamp on the dll you are using match the timestamp of the dll that created the dump? That would be one easy reason for the problem. If you have rebuilt the DLL, or grabbed the wrong version it seems like an easy fix. This is because you have a minidump and the timestamp for mydll.dll is not present in the dump.
This is because you have a minidump and the timestamp for mydll.dll is not present in the dump. If you add the original mydll.dll to the binary path ( .exepath) you will get rid of the warning.
* Symbols can not be loaded because symbol path is not initialized. * * using the _NT_SYMBOL_PATH environment variable. * * using the -y <symbol_path> argument when starting the debugger. * * Symbols can not be loaded because symbol path is not initialized. * * using the _NT_SYMBOL_PATH environment variable. *
To start viewing messages, select the forum that you want to visit from the selection below. I use CrashRpt library (can be found here) to get crash dump when my program crashes. I then open this dump file in WinDbg.
Check if you are using mini dump. If yes then you have to provide additional info which is binary path (exe\dll path) to add exepath execute this command -
.exepath+ "Path of dll\exe"
84
The reason might be that you don’t have the the binary for your mydll.dll
available.
Try to either put it in the same location as the .pdb or use the File -> Image path to
point at the location. NB both the .pdb and .dll must be the same version as the program dumped.
38
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
