When writing C# code in Visual Studio and in debug mode, the program cannot be launched.

The behavior indicates that the app crashes immediately when started under the debugger on this machine, but not when started normally or on other machines. In this situation, use the debugger and crash dump analysis to identify the real faulting code instead of relying on the generic event log entry.

Try the following steps on the problematic machine:

1. Start the app under the debugger
   • Open the solution in Visual Studio.
   • Set the configuration to Debug.
   • Press F5 (Debug > Start Debugging).
   • When the message appears that the process has ended, check whether Visual Studio breaks at an exception or shows any call stack. If it does, inspect the Call Stack and Autos/Locals/Watch windows to see which line of code is failing and what exception is thrown.
   • If the app terminates without showing an exception in Visual Studio, enable breaking on all exceptions in Debug > Windows > Exception Settings, then run again so the debugger stops at the first thrown exception.
2. If the debugger cannot attach
   • If the issue is that the debugger itself cannot attach to the process (for example, the process exits before Visual Studio can debug it), use Just-In-Time debugging:
     1. Make sure Just-In-Time debugging is enabled in Tools > Options > Debugging > Just-In-Time.
     2. Run the built OBC.exe directly from F:\0 c#近期维护\0 OBC PCTOOL - ATS\bin\OBC_PCTOOL\.
     3. When the crash occurs, the Choose Just-In-Time Debugger dialog should appear. Select a new instance of Visual Studio and click OK. Execution will stop at the line that throws the exception, and you can inspect the call stack and variables.
3. If Just-In-Time debugging does not start
   • If the Just-In-Time dialog never appears when the app crashes, adjust the Windows registry as documented:
     • Add a DWORD value named Auto with value 1 under:
       • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug
       • HKEY_LOCAL_MACHINE\Software\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug (for 32-bit .NET apps on 64-bit Windows).
     • If Windows Error Reporting is taking over, add a DWORD value named Disabled with value 1 under:
       • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting
       • HKEY_LOCAL_MACHINE\Software\WOW6432Node\Microsoft\Windows\Windows Error Reporting (for 32-bit apps on 64-bit Windows).
   • After changing these keys, run OBC.exe again and attach with Just-In-Time debugging as in step 2.
4. Analyze the crash cause
   • Once Visual Studio is attached at the crash point (either via F5 or Just-In-Time), use the Call Stack and Autos/Locals/Watch windows to identify which code path is causing the access violation (0xc0000005).
   • Compare with the behavior on the other machine where debugging works to see if any environment-specific code (file paths, registry access, hardware access, native DLLs, etc.) is different.

If the crash is in native or runtime code (for example, a C++/CLI or P/Invoke call), capture a full dump and analyze it with WinDbg, loading the correct symbols, to see the exact native call stack and failing module.

References:

• Debug using the Just-In-Time Debugger in Visual Studio
• Debug for absolute beginners
• Make code work in Visual Studio
• Quickstart: Debug with C# or Visual Basic using the Visual Studio debugger
• Application crashing faulting module MSVC100.DLL - Microsoft Q&A