0xC0000005 Access violation on a CreateEvent() call

  • Thread starter Thread starter socatoa
  • Start date Start date
S

socatoa

Hi,

I have a DLL in VC6, when a specific function is called it will spawns a
few threads and then return. The threads stay running and inside one of these
threads an event is created using the win32 CreateEvent() call:

Code Snippet

static HANDLE hReadyEvent;

......
// inside a thread
hReadyEvent = CreateEvent (NULL, FALSE, FALSE, "DataReady") ;
if (hReadyEvent == NULL)
{
// Error condition
return ;
}
......
// The event is passed to a kernel mode driver, the threads waits for this
event to be set by the driver. which it does without a problem
retVal = WaitForSingleObject (hReadyEvent, INFINITE);
if (retVal != WAIT_OBJECT_0)
{
//error condition
return ;
}
// once the thread is finished with the work then closes the handle
if (hReadyEvent != NULL)
CloseHandle(hReadyEvent);

Once the thread is done with the work, it will terminate itself and the
other threads. When the specific call from the DLL is called again, then the
threads will be spawned again, the event will be created again although the
handle is a static global handle.

This code has been working for many years as is but only when it is been
running in a multiprocessor system will fail sporadically. The createEvent()
call throws an access violation, but it does not do it every time, it
occurss very sporadically. Below is the dump file from this exception:

This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(710.e60): Access violation - code c0000005 (first/second chance not
available)
eax=03b50000 ebx=7c809c28 ecx=00001000 edx=7c90eb94 esi=0000019c edi=00000000
eip=7c90eb94 esp=0482e6f0 ebp=0482e754 iopl=0 nv up ei ng nz ac pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000297
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret
0:011> !analyze -v
*******************************************************************************
*
*
* Exception Analysis
*
*
*
*******************************************************************************
.....

FAULTING_IP:
ListMode!AcqControl+a8 [\pet\pet_common\source\ListMode/Listmode.cpp @ 1491]
004e3fc8 8b0a mov ecx,dword ptr [edx]

EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 004e3fc8 (ListMode!AcqControl+0x000000a8)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 036ed958
Attempt to read from address 036ed958

DEFAULT_BUCKET_ID: INVALID_POINTER_READ

PROCESS_NAME: AcqRemServer.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced
memory at "0x%08lx". The memory could not be "%s".

READ_ADDRESS: 036ed958

MANAGED_STACK: !dumpstack -EE
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of
mscorwks.dll is
in the version directory
3) or, if you are debugging a dump file, verify that the file
mscordacwks_<arch>_<arch>_<version>.dll is on your symbol
path.
4) you are debugging on the same architecture as the dump file.
For example, an IA64 dump file must be debugged on an IA64
machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.

LAST_CONTROL_TRANSFER: from 7c90e2dc to 004e3fc8

STACK_TEXT:
0482ffac 7c90e2dc 7c918e85 7c80b50b 00000000 ListMode!AcqControl+0xa8
[\pet\pet_common\source\ListMode/Listmode.cpp @ 1491]
0482ffb0 7c918e85 7c80b50b 00000000 00000000
ntdll!ZwRegisterThreadTerminatePort+0xc
0482ffb8 00000000 00000000 0121d3bc 00000000 ntdll!CsrNewThread+0xb


FAULTING_THREAD: 00000e60

PRIMARY_PROBLEM_CLASS: INVALID_POINTER_READ

BUGCHECK_STR: APPLICATION_FAULT_INVALID_POINTER_READ

FOLLOWUP_IP:
ListMode!AcqControl+a8 [\pet\pet_common\source\ListMode/Listmode.cpp @ 1491]
004e3fc8 8b0a mov ecx,dword ptr [edx]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: ListMode!AcqControl+a8

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: ListMode

IMAGE_NAME: ListMode.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 47be9650

STACK_COMMAND: ~11s; .ecxr ; kb

FAILURE_BUCKET_ID: ListMode.dll!AcqControl_c0000005_INVALID_POINTER_READ

BUCKET_ID: APPLICATION_FAULT_INVALID_POINTER_READ_ListMode!AcqControl+a8

Followup: MachineOwner
---------

The line Listmode.cpp @ 1491 points to the createEvent() call. I just don't
understand how the CreateEvent() call can cause the access violation or what
could cause this to happened.

Please if somebody can help me, I will really appreciate it.

Thanks in advance,
Socatoa
 
Hi,

I have a DLL in VC6, when a specific function is called it will spawns a
few threads and then return. The threads stay running and inside one of these
threads an event is created using the win32 CreateEvent() call:

Code Snippet

static HANDLE hReadyEvent;

.....
// inside a thread
hReadyEvent = CreateEvent (NULL, FALSE, FALSE, "DataReady") ;
if (hReadyEvent == NULL)
{
// Error condition
return ;
}
.....
// The event is passed to a kernel mode driver, the threads waits for this
event to be set by the driver. which it does without a problem
retVal = WaitForSingleObject (hReadyEvent, INFINITE);
if (retVal != WAIT_OBJECT_0)
{
//error condition
return ;
}
// once the thread is finished with the work then closes the handle
if (hReadyEvent != NULL)
CloseHandle(hReadyEvent);

Once the thread is done with the work, it will terminate itself and the
other threads. When the specific call from the DLL is called again, then the
threads will be spawned again, the event will be created again although the
handle is a static global handle.

This code has been working for many years as is but only when it is been
running in a multiprocessor system will fail sporadically. The createEvent()
call throws an access violation, but it does not do it every time, it
occurss very sporadically.
Click to expand...

Why does the handle need to be static? If the code you've shown above is
run by only one thread, why not use a local variable? On the other hand, if
multiple threads are waiting on the event, calling CloseHandle when there
are extant waits is undefined. I don't see how that could cause an access
violation the next time you call CreateEvent, but it wouldn't hurt to
check.
 
Hi Doug,

Thank you for your response. Only one thread is waiting for the event but
the handle is static because of the clean up mechanism that is implemented
which is not part of that thread but it is a global routine to clean up many
different things.
But when handle is closed from the clean up routine, the createEvent() is
always called before the event is used again. Is there something else I could
check?

Thanks,
Catalina
 
Back
Top