Problem with unmanaged Memory
b.hemmer
Posts: 5
Hello,
we have a huge problem with unmanaged memory in our .NET Application. So we decided to analyze the problem with the ants memory profiler. After the startup of the application we took a snapshot and before closing the application. Between that we did more Snapshots but i´m refering the first and last one.
On the first snapshot we had that parameters:
On the second snapshot we had that parameters:
A look on the unmanaged memory breakdown by module showed us that every module used approximately the same memory. The only exception is the user32 module. That used 4 MB more memory due to the first snapshot. But that does not declare the 60 MB unmanaged memory difference between snapshot 1 and 2. I´m guessing that we have a problem with a leak on the stack and not on the heap. Are there some tools by ants memory profiler to detect a leak like that?
with best regards
bernd hemmer
we have a huge problem with unmanaged memory in our .NET Application. So we decided to analyze the problem with the ants memory profiler. After the startup of the application we took a snapshot and before closing the application. Between that we did more Snapshots but i´m refering the first and last one.
On the first snapshot we had that parameters:
- Managed Memory: 129 MB
- Unused Memory: 33 MB
- Unmanaged Memory 265 MB
On the second snapshot we had that parameters:
- Managed Memory: 122 MB
- Unused Memory: 40 MB
- Unmanaged Memory 324 MB
A look on the unmanaged memory breakdown by module showed us that every module used approximately the same memory. The only exception is the user32 module. That used 4 MB more memory due to the first snapshot. But that does not declare the 60 MB unmanaged memory difference between snapshot 1 and 2. I´m guessing that we have a problem with a leak on the stack and not on the heap. Are there some tools by ants memory profiler to detect a leak like that?
with best regards
bernd hemmer
Comments
It does look like the stack memory is what's growing, but I'm afraid we don't have a tool that will show more details about the stack.
You may find windbg useful--you can use ~*k to dump call stacks for all threads.
Hope that might help!
Kind regards,
Jessica Ramos
Jessica Ramos | Product Support Engineer | Redgate Software
Have you visited our Help Center?
i tried that. I found that we have problems with our handles. When i´m looking in the tskmgr the handle count grows staticly and is not going back. I got the information via windbg that the thread and event handles are growing. But i dont get the information at which point they are allocated. Do you have some idea on that?
with best regards
bernd