Application crashing faulting module MSVC100.DLL

Thales 0 Reputation points

I took a dmp from my application crash see below : (just would like to know if issue is a problematic dll MSVC100.DLL or the code is the issue ? 

0:004> kb
 # ChildEBP RetAddr      Args to Child             
00 03dee36c 76da24c0     00000003 03dee95c 00000001 ntdll!NtWaitForMultipleObjects+0xc
01 03dee500 76da23b8     00000003 03dee95c 00000000 KERNELBASE!WaitForMultipleObjectsEx+0xf0
02 03dee51c 76ee7162     00000003 03dee95c 00000000 KERNELBASE!WaitForMultipleObjects+0x18
03 03dee998 76ee6ba6     00000000 00000000 00000001 kernel32!WerpReportFaultInternal+0x59d
04 03dee9b4 76ebe829     03deea54 76e2dc3a 03deea68 kernel32!WerpReportFault+0x9b
05 03dee9bc 76e2dc3a     03deea68 00000001 304f5146 kernel32!BasepReportFault+0x19
06 03deea54 67e3aefd     03deea68 00000000 00000001 KERNELBASE!UnhandledExceptionFilter+0x25a
07 03deed90 67e3d6fd     00000003 40000015 00000001 msvcr100!_call_reportfault+0x107 [f:\dd\vctools\crt_bld\self_x86\crt\src\invarg.c @ 254]
08 03deeda0 67e3383d     214cd73d 00000000 00000000 msvcr100!abort+0x28 [f:\dd\vctools\crt_bld\self_x86\crt\src\abort.c @ 83]
09 03deedd0 00488697     03deee6c 76e2db52 03deee9c msvcr100!terminate+0x33 [f:\dd\vctools\crt_bld\self_x86\crt\prebuild\eh\hooks.cpp @ 115]
WARNING: Stack unwind information not available. Following frames may be wrong.
0a 03deedd8 76e2db52     03deee9c 304f557e 00000000 ascmanager!std::_Init_locks::operator=+0xad2 
0b 03deee6c 7746de77     03deee9c 77443190 03defb34 KERNELBASE!UnhandledExceptionFilter+0x172
0c 03defb34 77431f34     ffffffff 7745362e 00000000 ntdll!__RtlUserThreadStart+0x3bf3d
0d 03defb44 00000000     004100e0 00000000 00000000 ntdll!_RtlUserThreadStart+0x1b

Basically 6 of my servers crashed with below sequence due to same ascmanager.exe 

DLL crashed at 20:00:58 ROCCEM1 (Standby)  Faulting module path:  D:\Softs\scspath\1\OCC\SCADAsoft\5.3.3_P11\xp-msvc10\dll\msvc\MSVCR100.dll
DLL crashed at 20:00:59 ROCCEM2(Online) Faulting module path: C:\Windows\SYSTEM32\MSVCR100.dll
DLL crashed at 20:00:58 ROCCCOM1 (Online)   Faulting module path: C:\Windows\SYSTEM32\MSVCR100.dll
DLL crashed at 20:00:56 ROCCCOM2 (Standby)  Faulting module path: C:\Windows\SYSTEM32\MSVCR100.dll
DLL crashed at 20:00:56 ROCCTRAF2  (Standby)  Faulting module path:  D:\Softs\scspath\1\OCC\SCADAsoft\5.3.3_P11\xp-msvc10\dll\msvc\MSVCR100.dll
DLL crashed at 20:00:56 ROCCTRAF1 (Online)  Faulting module path:  D:\Softs\scspath\1\OCC\SCADAsoft\5.3.3_P11\xp-msvc10\dll\msvc\MSVCR100.dll
0 comments No comments
Sign in to comment

Answer recommended by moderator

Danny Nguyen (WICLOUD CORPORATION) 7,185 Reputation points • Microsoft External Staff • Moderator

Hi,

MSVCR100.dll shows up as the faulting module could mean that’s where the Visual C++ 2010 runtime finally terminates the process.

Your stack shows the following:

  • Goes through msvcr100!_call_reportfault -> abort -> terminate -> KERNELBASE!UnhandledExceptionFilter.
  • Shows invarg.c on the path, which is the CRT’s invalid-parameter/abort handling.
  • Mentions ascmanager!std::_Init_locks::operator=, but unwind info is unreliable there, so don’t assume static initialization is definitely the root cause without symbols.

This pattern usually means your code or a linked library:

  • Passed an invalid parameter to a checked CRT function
  • Let a C++ exception escape all handlers so std::terminate was called
  • Called abort() or hit an assertion.

To narrow it down:

  1. Capture a full dump (e.g. procdump -ma ascmanager.exe) and load PDBs for ascmanager.exe.
  2. In WinDbg run: !analyze -v, then .ecxr, .exr -1, kb to see the real exception and call stack in your code.
  3. Optionally add logging handlers (_set_invalid_parameter_handler, std::set_terminate) and, if needed, enable Application Verifier + PageHeap to catch earlier memory misuse.

Hope this helps

  1. Thales 0 Reputation points

    Actually we have 6 servers, all of them had this crash, the version of visual studio installed in all of them are different, will it help if I delete the Microsoft Visual 2010 from below to make all same, as the dll inside the software D:\Softs\scspath\1\OCC\SCADAsoft\5.3.3_P11\xp-msvc10\dll\msvc\MSVCR100.dll is actually the one on which testing was done.👁 User's image

  2. Danny Nguyen (WICLOUD CORPORATION) 7,185 Reputation points • Microsoft External Staff • Moderator

    Having multiple VC++ versions (2005, 2008, 2010, 2013, 2015–2019; x86/x64) side‑by‑side is normal. Removing Visual C++ 2010 or other runtimes” is not recommended and is very unlikely to fix this crash, it may even break other apps.

    If you want consistency, the right way is to decide which VC++ 2010 runtime ascmanager.exe should use (your private D:\Softs\...\MSVCR100.dll or the system one) and adjust your deployment/manifest accordingly. But that’s more like a clean‑up step.

    To actually find the cause, you’ll need to inspect one of the crash dumps with symbols for ascmanager.exe (in WinDbg, !analyze -v, then look at the first frame in your code before

  3. Deleted

    This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Sign in to comment

1 additional answer

  1. AI answer

    Based on the information provided, the crashes involving MSVCR100.DLL suggest that there may be an issue with the code that is utilizing this DLL rather than the DLL itself being problematic. The stack trace indicates that the crash is occurring during a call to the C runtime library, which is often a result of improper memory management or unhandled exceptions in the application code.

    To further investigate:

    1. Check the application logs for any unhandled exceptions or errors that occurred prior to the crash.
    2. Review the code for potential issues such as memory leaks, buffer overflows, or improper use of pointers that could lead to the crash.
    3. Ensure that the version of MSVCR100.DLL being used is compatible with your application and is not corrupted. You may want to consider updating or reinstalling the Visual C++ Redistributable package that includes this DLL.
    4. If the application is multi-threaded, ensure that proper synchronization is being used to avoid race conditions that could lead to crashes.

    In summary, while MSVCR100.DLL is involved in the crash, the root cause is likely within the application code itself, and further debugging is needed to pinpoint the exact issue.

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer