While .NET gets all the press, love and attention, hard core C++ native development still pays the bills for many of us. As it’s just a few days before the mass geekfest which will be all about everything .NET I thought it was time to release a new CrashFinder! Grab the latest version here with all its 32-bit and 64-bit goodness. I’ve fixed all the bugs everyone’s reported so this is the one you’ll want to use.
As Visual Studio 2008 has been out for over a year, and I needed to update the symbol engine code to use later versions of DBGHELP.DLL, I’ve had to drop support for previous versions of Visual Studio. If you do need to use an earlier version of the compiler, you’ll need to set up the latest Platform SDK and use the headers and libs from it. If you don’t want to destabilize your development environment, you can probably just get by with copying DBGHELP.H and DBGHELP.LIB and setting up your project to include and link against them respectively, as that’s all that you need.
Speaking of DBGHELP, I was asked a good question the other day: if I want to use tools like CrashFinder, or do my own symbol loading, how to I use a symbol server? If you read the docs for SymInitialize, it says if you set the second parameter, the symbol path, to NULL, DBGHELP.DLL will use _NT_SYMBOL_PATH to find symbols. The person asking the question was deploying the latest DBGHELP.DLL from WinDBG with their application but they never saw symbols from the Microsoft symbol servers in their load application. To get the full symbol server support, you’ll also need to drop SYMSRV.DLL in the directory where you install DBGHELP.DLL. The Debugging Tools for Windows package (AKA WinDBG) includes the most recent DBGHELP.DLL and SYMSRV.DLL. The great news is that both are fully redistributable with your applications. If you need to prove this to your company’s lawyers, see REDIST.TXT in the Debugging Tools for Windows directory.
Most of you reading this don’t remember the original article for which I wrote CrashFinder, which was over ten years ago in April 1998 Microsoft Systems Journal. (For some reason lately I have felt compelled to scream “Get off my grass!” and take naps.) I’ve been deeply honored over the years for everyone who’s told me they found it useful. Thank you.
As always, if you find any bugs or have feature requests either write in the comments or email me (john at this company’s domain).
Microsoft Azure and Amazon Web Services (AWS) are two of the most popular cloud platforms.…
Cloud management is difficult to do manually, especially if you work with multiple cloud…
Azure’s scalable infrastructure is often cited as one of the primary reasons why it's the…
https://www.youtube.com/watch?v=wDzCN0d8SeA Watch our "Unlocking the Power of AI in your Software Development Life Cycle (SDLC)"…
FinOps is a strategic approach to managing cloud costs. It combines financial management best practices…
Using Kubernetes with Azure combines the power of Kubernetes container orchestration and the cloud capabilities…
View Comments
One question: what's native code?
The 'here' link to download the latest version seems to be broken :(
All,
Sorry! I messed up the download link. It's fixed now.
Haha, Jeff. :)
-John Robbins
Thanks John! Wow, that was ten years ago?
Harold,
Yes, sadly, it was. Do you feel as old as I do now? :)
- John Robbins
Hi,
Do you have a binary only package?
I'm still using VS2005 here and VC++2008 Express Edition doesn't build it.
[bad English. Sorry!]
CrashFinder start:
----------
Debug:
Unhandled exception at 0x7c80e755 in CrashFinder.EXE: 0xC0000005: Access violation writing location 0x00030ffc.
------------
Release:
CrashFinder.EXE has triggered a breakpoint
----------
My environment:
WinDBG - dbg_x86_6.10.3.233.msi
(dbghelp.dll, symsrv.dll - v.6.10.3.233, )
VS 2008 SP1
What's wrong with my build of the CrashFinder?
Warm regards,
Slava V.
[Bad Englihs.Sorry.]
When I build and run CrashFunder I got next errors:
1:
CrashFinder.EXE has triggered a breakpoint
2:
Unhandled exception at 0x7c964ed1 in CrashFinder.EXE: 0xC0000142: DLL Initialization Failed.
3:
Unhandled exception at 0x7c80e755 in CrashFinder.EXE: 0xC0000005: Access violation writing location 0x00030ffc.
Under IDE debugger (crtlib.c):
/* check condition (4) */
{
ACTCTX_SECTION_KEYED_DATA askd = { sizeof(askd) };
if (!(*pfnFindActCtxSectionStringW)(0, NULL, ACTIVATION_CONTEXT_SECTION_DLL_REDIRECTION, _CRT_DLL_FILENAME, &askd))
{
/* no activation context used to load CRT DLL, means no manifest present in the process */
return FALSE;
}
}
In my case - return FALSE.
As I have understood the CRT manifest is a problem.
My build environments are:
VS 2008 TeamSuit SP1 (FeaturePack beta installed too).
WinDBG - dbg_x86_6.10.3.233.msi
Dependancy Walker reports me about MFC and CRT :
C:windowswinsxsx86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e
C:windowswinsxsx86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_405b0943
DBGHelp and SYMSRV - V.6.10.0003.233.
All modules are present.
What's wrong with my CrashFinder build?
Warm regrads,
Slava V.
My best guess the problem may be one of the following:
1. The CRT DLL has been registered incorrectly on your machine. Try a repair install of VS to fix it.
2. The manifest in CrashFinder.EXE is invalid. Go into the project settings and turn off the manifest option and turn it back on.
We now have [first ever?] humor book for debugging folks --dumps, bugs and debugging forensics... available for order on Amazon :) John, I hope you don't mind your cartoon in there :p
http://www.amazon.com/gp/product/1906717257?ie=UTF8&tag=idebug_in_windbg-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1906717257