T
tib75
Guest
I am looking at a WinDbg dump whose analysis contains the following:
FAULTING_MODULE: 76dd0000 ntdll
DEBUG_FLR_IMAGE_TIMESTAMP: 4d8cef27
ERROR_CODE: (NTSTATUS) 0xc0000264 - {Application Error} The application attempted to release a resource it did not own. Click OK to terminate the application.
EXCEPTION_CODE: (NTSTATUS) 0xc0000264 - {Application Error} The application attempted to release a resource it did not own. Click OK to terminate the application.
This exception occurs after a the following code is called from our application. This code can run on weeks on end and then BANG... I get a dump with the above error.
I know it seems weird but there really is not any code between these two Critical Section statements. This code is used as a embedded "safety" check to ensure that no other thread is reading and it is safe move to do other write logic work below which is protected by its own Critical Section.
{ EnterCriticalSection(&m_csReadLock);
// if we made it here, there is no read in progress
LeaveCriticalSection(&m_csReadLock);
}
What is confusing me is the thread that dumps is the OwningThread for the critical section. Meaning the other threads (11), which are waiting to write, show the Critical Section for the read lock with an OwningThread of Zero. It appears that LeaveCriticalSection at least partially completes and the OwningThread for m_csReadLock structure seems to have been zeroed out. And it is zero everywhere. Running a test case that doesn't fail, shows that is the expected behavior.
We are running Windows Server 2008 Standard SP2, 2.9GHz, Quad CPU (2 proc), 4 Gig Mem, 32 bit OS. This code was originally built with VS6.0 and has been ported to VS2005.
How can this occur other than memory corruption of some type?
Is there any know bug in this area? I can’t seem to find much online regarding this particular error.
Is there anything intrinsically wrong with doing the Enter/Leave critical section one after the other?
I obviously suspect a threading issue. It just does not seem to be the case due to the consistency of the dump.
Any help is appreciated.
Continue reading...
FAULTING_MODULE: 76dd0000 ntdll
DEBUG_FLR_IMAGE_TIMESTAMP: 4d8cef27
ERROR_CODE: (NTSTATUS) 0xc0000264 - {Application Error} The application attempted to release a resource it did not own. Click OK to terminate the application.
EXCEPTION_CODE: (NTSTATUS) 0xc0000264 - {Application Error} The application attempted to release a resource it did not own. Click OK to terminate the application.
This exception occurs after a the following code is called from our application. This code can run on weeks on end and then BANG... I get a dump with the above error.
I know it seems weird but there really is not any code between these two Critical Section statements. This code is used as a embedded "safety" check to ensure that no other thread is reading and it is safe move to do other write logic work below which is protected by its own Critical Section.
{ EnterCriticalSection(&m_csReadLock);
// if we made it here, there is no read in progress
LeaveCriticalSection(&m_csReadLock);
}
What is confusing me is the thread that dumps is the OwningThread for the critical section. Meaning the other threads (11), which are waiting to write, show the Critical Section for the read lock with an OwningThread of Zero. It appears that LeaveCriticalSection at least partially completes and the OwningThread for m_csReadLock structure seems to have been zeroed out. And it is zero everywhere. Running a test case that doesn't fail, shows that is the expected behavior.
We are running Windows Server 2008 Standard SP2, 2.9GHz, Quad CPU (2 proc), 4 Gig Mem, 32 bit OS. This code was originally built with VS6.0 and has been ported to VS2005.
How can this occur other than memory corruption of some type?
Is there any know bug in this area? I can’t seem to find much online regarding this particular error.
Is there anything intrinsically wrong with doing the Enter/Leave critical section one after the other?
I obviously suspect a threading issue. It just does not seem to be the case due to the consistency of the dump.
Any help is appreciated.
Continue reading...