0xC0000005 Access violation on a CreateEvent() call

[=?Utf-8?B?c29jYXRvYQ==?=]

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 = WaitForSingleOb ject (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(hRe adyEvent);

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!KiFastSys temCallRet:
7c90eb94 c3 ret
0:011!analyze -v
*************** *************** *************** *************** *************** ****
*
*
* Exception Analysis
*
*
*
*************** *************** *************** *************** *************** ****
.....

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

EXCEPTION_RECOR D: ffffffff -- (.exr 0xfffffffffffff fff)
ExceptionAddres s: 004e3fc8 (ListMode!AcqCo ntrol+0x000000a 8)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameter s: 2
Parameter[0]: 00000000
Parameter[1]: 036ed958
Attempt to read from address 036ed958

DEFAULT_BUCKET_ ID: INVALID_POINTER _READ

PROCESS_NAME: AcqRemServer.ex e

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_<ar ch>_<arch>_<ver sion>.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_TR ANSFER: from 7c90e2dc to 004e3fc8

STACK_TEXT:
0482ffac 7c90e2dc 7c918e85 7c80b50b 00000000 ListMode!AcqCon trol+0xa8
[\pet\pet_common \source\ListMod e/Listmode.cpp @ 1491]
0482ffb0 7c918e85 7c80b50b 00000000 00000000
ntdll!ZwRegiste rThreadTerminat ePort+0xc
0482ffb8 00000000 00000000 0121d3bc 00000000 ntdll!CsrNewThr ead+0xb
FAULTING_THREAD : 00000e60

PRIMARY_PROBLEM _CLASS: INVALID_POINTER _READ

BUGCHECK_STR: APPLICATION_FAU LT_INVALID_POIN TER_READ

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

SYMBOL_STACK_IN DEX: 0

SYMBOL_NAME: ListMode!AcqCon trol+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!Ac qControl_c00000 05_INVALID_POIN TER_READ

BUCKET_ID: APPLICATION_FAU LT_INVALID_POIN TER_READ_ListMo de!AcqControl+a 8

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

[Doug Harrison [MVP]]

On Thu, 1 May 2008 11:14:00 -0700, socatoa
<so*****@discus sions.microsoft .comwrote:

>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 = WaitForSingleOb ject (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(hRe adyEvent);

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.

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.

--
Doug Harrison
Visual C++ MVP

[=?Utf-8?B?c29jYXRvYQ==?=]

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