error with device driver handle

I have a device driver, that does great and wonderful (at least I'm proud of it)
things. It sets up a symbolic handle via:

// Setup our name and symbolic link.
RtlInitUnicodeString (&deviceNameUnicodeString, g_deviceNameBuffer );
RtlInitUnicodeString (&deviceLinkUnicodeString, g_deviceLinkBuffer );
// Set up the basic Mydevice. We set up filter devices regularly
// as they are added. This is only for IOCTL control.
Status = IoCreateDevice ( DriverObject,
CONTROL_DEVICE_EXTENSION_SIZE, // For driver
extension
&deviceNameUnicodeString,
FILE_DEVICE_UNKNOWN,
FILE_DEVICE_SECURE_OPEN,
FALSE,
&g_MyDevice );

Status = IoCreateSymbolicLink (&deviceLinkUnicodeString,
&deviceNameUnicodeString );

I have a simple user mode application (cpp) that opens a handle to the driver
during initialization by:

g_MyCntrl = CreateFile(g_deviceLinkBuffer, GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, NULL);

where g_MyCntrl & g_deviceLinkBuffer are global values and g_deviceLinkBuffer is
L"\\\\.\\MyCntrl" a symbolic link my driver sets up.

The user mode application does its thing and tests all of the IOCTLs in the
driver. Works perfectly. However, as my application reaches the end, I call
the following:
printf("\nClosing handle...");
if (CloseHandle(g_DarkCntrl))
printf("\nHandle closed.");
else
printf("\nHandle failed to be closed.");

The application only shows the "Closing handle..." and in WinDbg I get:
Access violation - code c0000005 (!!! second chance !!!)
nt!IopfCallDriver+0x28:
804ee120 8b7108 mov esi,dword ptr [ecx+8]

Even with no CloseHandle (yes I know that is bad programming, but I was testing
it). I still get the same access violation. Furthermore, commenting out the code
that establishes the handle and taking a code path that does not involve testing
IOCTLs has no access error (same path taken with establishing the handle
uncommented gets the access violation).

I am completely stumped. All the way right before the end of the program
(without calling CloseHandle) or even prior to entering CloseHandle g_MyCntrl is
the same value since it is assigned. I don't see how it can be having an access
violation to something that is there and its been successfully using prior to.

Any thoughts?

Write the program which contains only CreateFile and CloseHandle and test it. What results do you have?

Same results... I'm guessing it is a driver side error...

Debug the CloseHandle and Unload driver handlers.
For Windows driver specific questions, the best place to ask is http://www.osronline.com/

This is resolved. Driver was missing handling for IRP_MJ_CLEANUP/CLOSE which are called by CloseHandle.