C# Windows 服务导入 C++ dll 崩溃，事件 ID：1000 clr.dll

Question

I have a Windows service which imports a C++ dll. If I do pressure test, this Windows service will directly crashed with Event ID: 1000 showed module clr.dll but didn't log any exception. Event message as below:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Error" />
    <EventID Qualifiers="0">1000</EventID>
    <Level>2</Level>
    <Task>100</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2020-10-26T08:22:52.027599500Z" />
    <EventRecordID>5246</EventRecordID>
    <Channel>Application</Channel>
    <Computer>computer</Computer>
    <Security />
  </System>
  <EventData>
    <Data>Server.exe</Data>
    <Data>5.1.0.1</Data>
    <Data>5f8d0a4f</Data>
    <Data>clr.dll</Data>
    <Data>4.7.3680.0</Data>
    <Data>5f233da8</Data>
    <Data>c0000409</Data>
    <Data>0056aa27</Data>
    <Data>1fc4</Data>
    <Data>01d6ab1690751cd9</Data>
    <Data>Server.exe</Data>
    <Data>C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll</Data>
    <Data>0772888d-b659-483c-b80b-d7b4de714636</Data>
    <Data>
    </Data>
    <Data>
    </Data>
  </EventData>
</Event>

I have tried some ways:

1. Windows Update
2. My C# project app.config add

    <configuration>
       <runtime>
          <legacyCorruptedStateExceptionsPolicy enabled="true" />
       </runtime>
    </configuration>

and the function which use C++ dll add

[HandleProcessCorruptedStateExceptions]
[SecurityCritical]

3. All code use C++ dll are all added try catch, but Windows service still crashed without log any exception.

Windows environment is Windows Server 2016 64bit. C++ dll is x86 thus I use x86 CPU - debug to build the project. I suspect the reason of crash caused by C++ dll but can't prove it.

Answer 1

It looks like the simple solution is to attach the debugger to the service. You'll need to start Visual Studio as Administrator probably, because the service likely runs under a non-interactive login.

The "CorruptedState" not-solutions are a throwback to IsBadReadPtr , another unreliable and flaky method that Microsoft invented in the past. While debugging, the debugger is the better solution. Once released to customers, neither approach is guaranteed to catch the problem.