none
mscorwks!CorExitProcess producing CPU load RRS feed

  • Question

  • Hello,

    I have a Windows Forms application written in C#. The application uses some third party .NET dlls and works flawlessly on several PCs. But when I run it on a new Core i7 PC it produces high processor load and it's threads are completely out of sync. I tried limiting it to 1 core which makes it use that one 100%. Then I had a look at the threads with ProcessExplorer.  The thread producing the most load has the following call stack:

    ntkrnlpa.exe+0x6e9ab
    ntkrnlpa.exe+0x2bf82
    hal.dll+0x2ef2
    ole32.dll!CoMarshalInterface+0xac1
    ole32.dll!CoMarshalInterface+0xaa4
    mscorwks.dll!CorExitProcess+0x1fea0
    mscorwks.dll!CorExitProcess+0x1ff2e
    mscorwks.dll!CorExitProcess+0x20035
    mscorwks.dll!CoUninitializeCor+0x313
    mscorwks.dll!CorExitProcess+0x10a6b
    mscorwks.dll!CorExitProcess+0x10b0a
    mscorwks.dll!CorExitProcess+0x10c2e
    mscorwks.dll!CorExitProcess+0x10cc3
    mscorwks.dll!DllGetClassObjectInternal+0x5a7a
    mscorlib.ni.dll+0x1f68af
    mscorlib.ni.dll+0x1f6865
    mscorlib.ni.dll+0x1f682d
    System.ni.dll+0x5b5ddd
    mscorlib.ni.dll+0x216d66
    mscorlib.ni.dll+0x2201ef
    mscorlib.ni.dll+0x216ce4
    mscorwks.dll+0x1b4c
    mscorwks.dll!DllUnregisterServerInternal+0x619d
    mscorwks.dll!CoUninitializeEE+0x2ead
    mscorwks.dll!CoUninitializeEE+0x2ee0
    mscorwks.dll!CoUninitializeEE+0x2efe
    mscorwks.dll!CorExitProcess+0x1e4d
    mscorwks.dll!CoUninitializeEE+0x4e0b
    mscorwks.dll!CoUninitializeEE+0x4da7
    mscorwks.dll!CoUninitializeEE+0x4ccd
    mscorwks.dll!CoUninitializeEE+0x4e59
    mscorwks.dll!CorExitProcess+0x1c1e
    mscorwks.dll!CorExitProcess+0x1cf8
    mscorwks.dll!CorExitProcess+0x21f3f
    KERNEL32.dll!GetModuleFileNameA+0x1ba

    Strangely enough I can kill this thread: The application still runs and it's processor load goes down to a few percent.

    Do you have an idea what this could be?

    thanks in advance,

    Fabian
    Friday, October 23, 2009 1:41 PM

Answers

  • Hello

    I run !runaway command to see the CPU time of each thread, and find that thread 37 runs for a very long time:
     
      37:132c      0 days 0:01:21.078

    Its call-stack is:
    0:037> k
    ChildEBP RetAddr 
    0e15ece0 7c90d28a ntdll!KiFastSystemCallRet
    0e15ece4 7c867405 ntdll!NtDeviceIoControlFile+0xc
    0e15ed24 03997c95 kernel32!WaitCommEvent+0x42
    0e15ed54 7a9f5d9d CLRStub[StubLinkStub]@3bfe1e003997c95
    0e15edb8 792d6d66 System_ni!System.IO.Ports.SerialStream+EventLoopRunner.WaitForCommEvent()+0x10d
    0e15edc4 792e01ef mscorlib_ni!System.Threading.ThreadHelper.ThreadStart_Context(System.Object)+0x66
    0e15edd8 792d6ce4 mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)+0x6f
    0e15edf0 79e71b4c mscorlib_ni!System.Threading.ThreadHelper.ThreadStart()+0x44
    0e15ee00 79e821b9 mscorwks!CallDescrWorker+0x33
    0e15ee80 79e96531 mscorwks!CallDescrWorkerWithHandler+0xa3
    0e15efb8 79e96564 mscorwks!MethodDesc::CallDescr+0x19c
    0e15efd4 79e96582 mscorwks!MethodDesc::CallTargetWorker+0x1f
    0e15efec 79f55623 mscorwks!MethodDescCallSite::Call+0x1a
    0e15f1d4 79e9848f mscorwks!ThreadNative::KickOffThread_Worker+0x192
    0e15f1e8 79e9842b mscorwks!ManagedThreadBase_DispatchInner+0x4f
    0e15f27c 79e98351 mscorwks!ManagedThreadBase_DispatchMiddle+0xb1
    0e15f2b8 79e984dd mscorwks!ManagedThreadBase_DispatchOuter+0x6d
    0e15f2e0 79f553f4 mscorwks!ManagedThreadBase_FullTransitionWithAD+0x25
    0e15f2f8 79f554ce mscorwks!ManagedThreadBase::KickOff+0x13
    0e15f394 79f75715 mscorwks!ThreadNative::KickOffThread+0x269
    0e15ffb4 7c80b729 mscorwks!Thread::intermediateThreadProc+0x49
    0e15ffec 00000000 kernel32!BaseThreadStart+0x37 
     
    So, as I suspected, the call-stack at first was not right for lack of correct symbols. According to the call-stack outputted on my side, the thread is busy with serial port operation:
    System_ni!System.IO.Ports.SerialStream+EventLoopRunner.WaitForCommEvent. 
     
    I next checked the source code of the method in Reflector, and found nothing useful.
     
    Then I searched "WaitForCommEvent high CPU site:*.microsoft.com" on the internet, and found these discussions:
     
    http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/8a1825d2-c84b-4620-91e7-3934a4d47330
    http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/ed9605b6-3c97-4b53-949a-f56f9da58306

    Please check these threads out, and see whether they are helpful to you.

    In addition, as far as I know, .NET 3.5 SP1 fixed a lot of product issues of SerialPort BCL. The issue in discussion may also be covered. Could you please confirm that you have .NET 3.5 SP1 on your system and the development machine? 



    Regards,
    Jialiang Ge
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

    Tuesday, October 27, 2009 7:50 AM
    Moderator

All replies

  • Hello Fabian

    The call-stack looks very wierd. I find on the Microsoft feedback site a similar issue report
    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=456466&wa=wsignin1.0#details
    However no cause/solution was found in this report for lack of repro.

    Fabian, could you please capture a hang dump file when CPU is high and send it to me?

    To capture the hang dump, please follow this KB article:
    http://support.microsoft.com/kb/286350


    Thanks
    Jialiang Ge
    Regards,
    Jialiang Ge
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, October 26, 2009 4:20 AM
    Moderator
  • Hello Jialiang,

    I've just finished uploading a dump file. In this case the app is locked to core 1. I've been doing this for years to reserve the other core(s) for a second app which is launched by the first one. As I said nothing has changed except the PC.

    thx in advance,

    Fabian
    Monday, October 26, 2009 8:29 AM
  • Thank. I have received your dump. I will analyze it and update you about my findings.
    Regards,
    Jialiang Ge
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    • Proposed as answer by Pipistrelo Monday, October 26, 2009 12:36 PM
    Monday, October 26, 2009 11:07 AM
    Moderator
  • Hello

    I run !runaway command to see the CPU time of each thread, and find that thread 37 runs for a very long time:
     
      37:132c      0 days 0:01:21.078

    Its call-stack is:
    0:037> k
    ChildEBP RetAddr 
    0e15ece0 7c90d28a ntdll!KiFastSystemCallRet
    0e15ece4 7c867405 ntdll!NtDeviceIoControlFile+0xc
    0e15ed24 03997c95 kernel32!WaitCommEvent+0x42
    0e15ed54 7a9f5d9d CLRStub[StubLinkStub]@3bfe1e003997c95
    0e15edb8 792d6d66 System_ni!System.IO.Ports.SerialStream+EventLoopRunner.WaitForCommEvent()+0x10d
    0e15edc4 792e01ef mscorlib_ni!System.Threading.ThreadHelper.ThreadStart_Context(System.Object)+0x66
    0e15edd8 792d6ce4 mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)+0x6f
    0e15edf0 79e71b4c mscorlib_ni!System.Threading.ThreadHelper.ThreadStart()+0x44
    0e15ee00 79e821b9 mscorwks!CallDescrWorker+0x33
    0e15ee80 79e96531 mscorwks!CallDescrWorkerWithHandler+0xa3
    0e15efb8 79e96564 mscorwks!MethodDesc::CallDescr+0x19c
    0e15efd4 79e96582 mscorwks!MethodDesc::CallTargetWorker+0x1f
    0e15efec 79f55623 mscorwks!MethodDescCallSite::Call+0x1a
    0e15f1d4 79e9848f mscorwks!ThreadNative::KickOffThread_Worker+0x192
    0e15f1e8 79e9842b mscorwks!ManagedThreadBase_DispatchInner+0x4f
    0e15f27c 79e98351 mscorwks!ManagedThreadBase_DispatchMiddle+0xb1
    0e15f2b8 79e984dd mscorwks!ManagedThreadBase_DispatchOuter+0x6d
    0e15f2e0 79f553f4 mscorwks!ManagedThreadBase_FullTransitionWithAD+0x25
    0e15f2f8 79f554ce mscorwks!ManagedThreadBase::KickOff+0x13
    0e15f394 79f75715 mscorwks!ThreadNative::KickOffThread+0x269
    0e15ffb4 7c80b729 mscorwks!Thread::intermediateThreadProc+0x49
    0e15ffec 00000000 kernel32!BaseThreadStart+0x37 
     
    So, as I suspected, the call-stack at first was not right for lack of correct symbols. According to the call-stack outputted on my side, the thread is busy with serial port operation:
    System_ni!System.IO.Ports.SerialStream+EventLoopRunner.WaitForCommEvent. 
     
    I next checked the source code of the method in Reflector, and found nothing useful.
     
    Then I searched "WaitForCommEvent high CPU site:*.microsoft.com" on the internet, and found these discussions:
     
    http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/8a1825d2-c84b-4620-91e7-3934a4d47330
    http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/ed9605b6-3c97-4b53-949a-f56f9da58306

    Please check these threads out, and see whether they are helpful to you.

    In addition, as far as I know, .NET 3.5 SP1 fixed a lot of product issues of SerialPort BCL. The issue in discussion may also be covered. Could you please confirm that you have .NET 3.5 SP1 on your system and the development machine? 



    Regards,
    Jialiang Ge
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

    Tuesday, October 27, 2009 7:50 AM
    Moderator
  • Hello

    How are you? May I know whether the above information is helpful to you? If you have any questions, please feel free to follow up.
    Regards,
    Jialiang Ge
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Thursday, October 29, 2009 7:40 AM
    Moderator