Hello all,
I am experiencing this weird bugcheck and would apreciate your help.
I am opening the file with this sequence:
//opens the log file for writing
NTSTATUS log_openLogFile(ULONG CreateDisposition) {
NTSTATUS status = 0;
OBJECT_ATTRIBUTES fileAttrs = {0};
IO_STATUS_BLOCK ioStatus = {0};
if(log_file != 0)
{
debug_assert(0);
return 0;
}
InitializeObjectAttributes(&fileAttrs, &log_fileName,
OBJ_KERNEL_HANDLE|OBJ_CASE_INSENSITIVE, NULL, NULL);
status = ZwCreateFile(
&log_file,
GENERIC_WRITE,
&fileAttrs,
&ioStatus,
0,
FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ,
CreateDisposition,
FILE_SYNCHRONOUS_IO_NONALERT,
0,
0);
if ( ! NT_SUCCESS(status)) {
debug_printf(DEBUG_ON, “[BDFNDISF][LOG] Cannot open the log file
(%ws). Status=0x%X”, log_fileName.Buffer, status);
} // [status]
return status;
} // [log_openLogFile()]
There are multiple threads that may write to the file, mostly from
worker items.
Thanks,
Andrei
*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************
DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
The IO manager has caught a misbehaving driver.
Arguments:
Arg1: 0000000c, Invalid IOSB in IRP at APC IopCompleteRequest (appears
to be on
stack that was unwound)
Arg2: f78cdef0, IOSB address
Arg3: 00000000, IRP address
Arg4: 00000000, 0
Debugging Details:
BUGCHECK_STR: 0xc9_c
DRIVER_VERIFIER_IO_VIOLATION_TYPE: c
IOSB_ADDRESS: fffffffff78cdef0
IRP_ADDRESS: 8773ce28
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT
PROCESS_NAME: System
DEVICE_OBJECT: 86ab7020
LAST_CONTROL_TRANSFER: from 8097f714 to 80822f13
STACK_TEXT:
f78cebec 8097f714 000000c9 0000000c f78cdef0 nt!KeBugCheckEx+0x1b
f78cec08 8081db39 8773ce68 f78ceca8 f78cecac nt!IovpCompleteRequest+0x4c
f78cec64 80827e91 8773ce68 f78cecb0 f78ceca4 nt!IopCompleteRequest+0x39
f78cecb4 80a0def2 00000000 00000000 f78ceccc nt!KiDeliverApc+0xb3
f78cecb4 80a0d99a 00000000 00000000 f78ceccc hal!HalpApcInterrupt+0xc6
f78ced3c f6e8ac89 86a21108 866f9b70 86bcdda8 hal!ExReleaseFastMutex+0x26
f78ced68 8089e9d5 866f9b70 866f1000 8088c7bc
bdfndisf!log_delayedWrite+0xb7
[e:\repository\firewall3\src\ndisim\bdflog\bdf_log.c @ 671]
f78ced7c 80860aff 86a21108 00000000 86bcdda8 nt!IopProcessWorkItem+0x13
f78cedac 808f7a08 86a21108 00000000 00000000 nt!ExpWorkerThread+0xef
f78ceddc 8086e46e 80860a10 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
STACK_COMMAND: kb
FOLLOWUP_IP:
bdfndisf!log_delayedWrite+b7
[e:\repository\firewall3\src\ndisim\bdflog\bdf_log.c @ 671]
f6e8ac89 3bde cmp ebx,esi
FAULTING_SOURCE_CODE:
667: ObReferenceObjectByHandle(fhandle, GENERIC_ALL, 0,
KernelMode, &pobj, 0);
668:
669: ExReleaseFastMutex(&logRenameLock);
670:
> 671: if ((fhandle != 0) && (entry->chunkOffset != 0)) {
672: NTSTATUS status;
673: LARGE_INTEGER offset = {FILE_WRITE_TO_END_OF_FILE, -1};
674:
675: status = ZwWriteFile(fhandle, 0, 0, 0, &ioStatus,
entry->chunk,
676: entry->chunkOffset, &offset, 0);
SYMBOL_STACK_INDEX: 6
SYMBOL_NAME: bdfndisf!log_delayedWrite+b7
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: bdfndisf
IMAGE_NAME: bdfndisf.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 46aded53
FAILURE_BUCKET_ID: 0xc9_c_bdfndisf!log_delayedWrite+b7
BUCKET_ID: 0xc9_c_bdfndisf!log_delayedWrite+b7