Member Avatar for risa

hi,
I get a crash as
"Unhandled exception at 0x5f4335bb (MFC42D.DLL) in VMFirewall.exe: 0xC0000005: Access violation reading location 0x00000000."
in D:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\src\mfc\appmodul.cpp in _tWinMain() funtion at call of AfxWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow);
This crash is in both debug and release....i have tried ignore of mfc42D.lib and mfcs42d.lib....but still m getting same problem,,,plz help

  • 2 Contributors
  • 2 Replies
  • 418 Views
  • 19 Hours Discussion Span
  • Latest Post Latest Post by risa

Dani AI

Generated

noted the crash happens before InitInstance, and was right that wide classes of bugs can cause an AV — but when the failure is inside MFC startup (AfxWinMain) the usual root causes are different from "ordinary" buffer overruns. The access to 0x00000000 at startup typically means MFC’s module/app state or a vtable pointer is null because something ran too early, or the process loaded the wrong MFC/CRT DLL (for example seeing MFC42D.DLL while building with VC8/VS2005 implies an old VC6 MFC is being pulled into the process).

Practical, ordered checks:

  • Break on first‑chance access violations (Debug → Exception Settings → Win32 exceptions → break when thrown) and inspect the full call stack and disassembly at the crash. The top user-space frame usually points to which object is null.
  • Open Debug → Windows → Modules to see exactly which MFC DLL was loaded and its path. If MFC42D.dll appears unexpectedly, a third‑party DLL or a stray copy on PATH is likely the cause.
  • Use Dependency Walker / Process Explorer to list static and runtime DLL dependencies and confirm every DLL was built with the same VC/MFC runtime (debug vs release, CRT settings).
  • Turn on symbol servers (Tools → Options → Debugging → Symbols → Microsoft Symbol Servers) so the stack frames show real function names/lines.

Common fixes and preventative steps:

  • Remove any MFC calls from global/static constructors. Move initialization into CWinApp::InitInstance or use lazy initialization. Example of a risky pattern to avoid:
    // risky: runs before AfxWinMain
static CString sName = AfxGetApp() ? AfxGetApp()->m_pszAppName : _T("");
  • Restore default MFC libraries (don’t ignore mfc*.lib unless you know why) and make sure “Use of MFC” and Runtime Library (MT/MD, debug/release) are consistent across the project and all static libs/DLLs. Rebuild third‑party libs if they were built with a different VC.
  • Test with a fresh MFC skeleton app: if it runs, the problem is project/code-specific; if it also crashes, the environment or mismatched DLLs are the likely culprits.

If the call stack shows pApp or module state as NULL, the fix is almost always to stop calling MFC from static initializers or to correct the mixed-MFC/CRT situation so the correct MFC DLL initializes first.

Recommended Answers

All 2 Replies

Member Avatar for Ancient Dragon

There are hundreds of reasons you get that problem, so its impossible for us to give you much more info without seeing the code. Try commenting out large portions of the program until the crash no longer happens, that way you can narrow down your search for the problem. Look for buffer overruns and uninitialized variables, especially pointers.

Member Avatar for risa

well i get this crash before start of my application i.e before entering InitInstance(),,,,so i guess its not a problem of buffer over run or un-initialized variables or pointers,,,

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.