WinDbg Address Summary

前端 未结 2 570
我在风中等你
我在风中等你 2020-12-31 14:47

Our wcf service hosted in IIS crashes (w3wp.exe ~ 1.6 GB) as the user load increases. We have got a dump through Debug Diag and ran this command in windbg. This is the outpu

2条回答
  •  谎友^
    谎友^ (楼主)
    2020-12-31 15:21

    WCF (Windows Communication Foundation) is a .NET technology. .NET does not make use of the Windows Heap Manager, so using any !heap command will not work for .NET. No wonder that it's small.

    Instead, the .NET framework has its own memory manager due to garbage collection. You already used the correct command !eeheap -gc to display information about the .NET heaps. The last line of that command says:

    GC Heap Size:            Size: 0x175de850 (392030288) bytes.
    

    So .NET is responsible for almost 400 MB of () memory. The rest could be caused by

    • direct calls to VirtualAlloc() of course
    • allocations via the Windows Heap Manager that are larger than 512 kb (see the statement by Sasha Goldshtein). This could be some C++ code, for example. Working with images or video could often fall into this category.
    • some versions of MSXML
    • potential other garbage collecting memory managers, e.g. the heap manager from Java (a guess, I never verified, but the Windows Heap Manager does not work well for garbage collecting)

    If these values remain constant, there's nothing to worry about. But if it increases, this might indicate a leak. I personally consider those 87000 timer callbacks as a potential source. What are all those timer callbacks doing? Are they ever able to finish their work?

    79baa808    87474      1749480 System.Threading._TimerCallback
    

提交回复
热议问题