Windows error 0x00000219, 537

Detailed Error Information

VERIFIER_STOP[1]

MessageApplication verifier has found an error in the current process.
Declared inwinerror.h

This appears to be a raw Win32 error. More information may be available in error 0x80070219.

HRESULT analysis[2]

This is probably not the correct interpretation of this error. The Win32 error above is more likely to indicate the actual problem.
FlagsSeveritySuccess

This code indicates success, rather than an error. This may not be the correct interpretation of this code, or possibly the program is handling errors incorrectly.

Reserved (R)false
OriginMicrosoft
NTSTATUSfalse
Reserved (X)false
FacilityCode0 (0x000)
NameFACILITY_NULL[2][1]
DescriptionThe default facility code.[2][1]
Error Code537 (0x0219)

Possible solutions

6

Investigating Memory Leak

windows
debugging
memory-management
memory-leaks
windbg

The stack recorded when using GFlags is done without utilizing .pdb and often not correct. Since you have traced the leak down to a specific size on a given heap, you can try to set a live break in RtlAllocateHeap and inspect the stack in windbg with proper symbols. I have used the following with some success. You must edit it to suit your heap and size.

 $$ Display stack if heap handle eq 0x00310000 and size is  0x1303
 $$ ====================================================================
bp ntdll!RtlAllocateHeap "j ((poi(@esp+4) = 0x00310000) & (poi(@esp+c) = 0x1303) )'k';'gc'" 

Maybe you then get another stack and other ideas for the offender.

answered on Stack Overflow Apr 10, 2012 by Kjell Gunnar • edited May 9, 2015 by Kjell Gunnar
2

Investigating Memory Leak

windows
debugging
memory-management
memory-leaks
windbg

The first thing is that the new operator is the new [] operator so is there a corresponding delete[] call and not a plain old delete call?

If you suspect this code I would put a test harness around it, for instance put it in a loop and execute it 100 or 1000 times, does it still leak and proportionally.

You can also measure the memory increase using process explorer or programmatically using GetProcessInformation.

The other obvious thing is to see what happens when you comment out this function call, does the memory leak go away? You may need to do a binary chop if possible of the code to reduce the likely suspect code by half (roughly) each time by commenting out code, however, changing the behaviour of the code may cause more problems or dependant code path issues which can cause memory leaks or strange behaviour.

EDIT Ignore the following seeing as you are working in a managed environment.

You may also consider using the STL or better yet boost reference counted pointers like shared_ptr or scoped_array for array structures to manage the lifetime of the objects.

answered on Stack Overflow Apr 5, 2012 by EdChum • edited Apr 6, 2012 by EdChum

Comments

Leave a comment

(plain text only)

Sources

  1. winerror.h from Windows SDK 10.0.14393.0
  2. https://msdn.microsoft.com/en-us/library/cc231198.aspx

User contributions licensed under CC BY-SA 3.0