BSOD minifilter driver when using named pipe with userland app

NTDEV
1

Hi everybody !

I’m working on a minifilter driver that will log few actions done on the disk by a processus. I was writing the logs directly from the minifilter through FltWriteFile and it was working well. Now I want to send the logs to an application running in userland, and this last one will write them to a file.

I have a lot of trouble with that part … Here is the function from the minifilter that will send the logs to the userland app through named pipe :

// send logs to userland app through Named Pipe
NTSTATUS sendLogs(ULONG pid, PWCHAR message, PUNICODE_STRING parameter)
{
NTSTATUS status;
IO_STATUS_BLOCK iosbStatus;
CHAR buf[MAXSIZE];

if(KeGetCurrentIrql() != PASSIVE_LEVEL)
{
DbgPrint(“[-] LOG > PASSIVE_LEVEL\n”);
return -1;
}

DbgPrint(“%ws ‘%wZ’\n”,message,parameter);

// send logs to named pipe and we use mutex to avoid concurrency
KeWaitForMutexObject(&mutex, Executive, KernelMode, FALSE, NULL);

if(NT_SUCCESS(RtlStringCbPrintfA(buf, MAXSIZE, “pid : %d, message : %ws, parameters : %wZ\n”, pid, message, parameter)))
{
DbgPrint(“[LOG] : %s”, buf);
if(buf)
{
//ZwWriteFile(hPipe, NULL, NULL, NULL, &iosbStatus, buf, MAXSIZE, NULL, NULL);
}
}

memset(buf, 0, sizeof(buf));
KeReleaseMutex(&mutex, FALSE);

return STATUS_SUCCESS;
}

If I comment the line ZwWriteFile, everything is working well, but I uncomment it, I got a BSOD !
The problem is not from the userland app, if i send instead of buf “aa\n” with size 3, it’s working well.

The communication pipes are initialized on the DriverEntry function in that way :

OBJECT_ATTRIBUTES objAttr;
UNICODE_STRING uPipe;
RtlInitUnicodeString(&uPipe, L"\DosDevices\pipe\logMF");

// initialize communication pipe with user app
InitializeObjectAttributes(&objAttr, &uPipe, OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, NULL, NULL);
status = ZwOpenFile(&hPipe, GENERIC_ALL, &objAttr, &iosbStatus, FILE_SHARE_READ | FILE_SHARE_WRITE, FILE_NON_DIRECTORY_FILE);

and in the unload function :
ZwClose(hPipe)

hPipe is global.

I really don’t see where I’m wrong, if you could point me out, it would be really helpful !

Thanks a lot !

2

I forgot to say : It’s only after ~ 5min of logging, that the bsod occurs !

3

> Hi everybody !

I’m working on a minifilter driver that will log few actions done on the
disk by a processus. I was writing the logs directly from the minifilter
through FltWriteFile and it was working well. Now I want to send the logs
to an application running in userland, and this last one will write them
to a file.

I have a lot of trouble with that part … Here is the function from the
minifilter that will send the logs to the userland app through named pipe
:

// send logs to userland app through Named Pipe
NTSTATUS sendLogs(ULONG pid, PWCHAR message, PUNICODE_STRING parameter)

Carefully read the above line. What is the return type?

{
NTSTATUS status;
IO_STATUS_BLOCK iosbStatus;
CHAR buf[MAXSIZE];

if(KeGetCurrentIrql() != PASSIVE_LEVEL)
{
DbgPrint(“[-] LOG > PASSIVE_LEVEL\n”);
return -1;

Having carefully read the return type line, what in the world suggested to
you that -1 could evever make sese? You would want to return
STATUS_something; I think there is one for “wrong state”. Someone else
foolishly returned “true” to mean “success” (and should have returned
“STATUS_SUCCESS”. Note that if you are sending this string to an app, you
can do it up to and including DISPATCH_LEVEL, so the test is no longer
necessary.

}

DbgPrint(“%ws ‘%wZ’\n”,message,parameter);

// send logs to named pipe and we use mutex to avoid concurrency
KeWaitForMutexObject(&mutex, Executive, KernelMode, FALSE, NULL);

Why a named pipe? Just complete a ReadFile request or DeviceIoControl
request. Then all you need is a spin lock, which removes the need for
PASSIVE_LEVEL so you can wait for a mutex.

if(NT_SUCCESS(RtlStringCbPrintfA(buf, MAXSIZE, “pid : %d, message : %ws,
parameters : %wZ\n”, pid, message, parameter)))

And presumably this logging is just for you, so localization is not required.

{
DbgPrint(“[LOG] : %s”, buf);
if(buf)
{
//ZwWriteFile(hPipe, NULL, NULL, NULL, &iosbStatus, buf, MAXSIZE, NULL,
NULL);
}
}

memset(buf, 0, sizeof(buf));

this is profoundly silly. You are erasing the contents of a local
variable right before it goes out of scope! Why?

KeReleaseMutex(&mutex, FALSE);

I would use a spinlock to protect the filling of the buffer and its
completion. I would set the lock, check for the presence of an IRP; if
none. record te data in an internal buffer ring. When the IRP comes down,
first, try to fulfill it from te buffer ring, and if that is empty, pend
it. So much simpler than the problems of creating named pipes and
limiting you logging to PASSIVE_LEVEL.
joe

return STATUS_SUCCESS;
}

If I comment the line ZwWriteFile, everything is working well, but I
uncomment it, I got a BSOD !

No, you don’t get “a BSOD” You grt a very specific error, which would be
accompanied by the !analyze -v output. Any other description is just
wasting out time!

The problem is not from the userland app, if i send instead of buf “aa\n”
with size 3, it’s working well.

The communication pipes are initialized on the DriverEntry function in
that way :

OBJECT_ATTRIBUTES objAttr;
UNICODE_STRING uPipe;
RtlInitUnicodeString(&uPipe, L"\DosDevices\pipe\logMF");

If the pipename doesn’t include a GUID as part of the name, you are asking
for trouble.

// initialize communication pipe with user app
InitializeObjectAttributes(&objAttr, &uPipe, OBJ_CASE_INSENSITIVE |
OBJ_KERNEL_HANDLE, NULL, NULL);
status = ZwOpenFile(&hPipe, GENERIC_ALL, &objAttr, &iosbStatus,
FILE_SHARE_READ | FILE_SHARE_WRITE, FILE_NON_DIRECTORY_FILE);

and in the unload function :
ZwClose(hPipe)

hPipe is global.

I would eliminate any use of a named pipe.

I really don’t see where I’m wrong, if you could point me out, it would be
really helpful !

Thanks a lot !

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

Here is the analyze -v output :

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

NTFS_FILE_SYSTEM (24)
If you see NtfsExceptionFilter on the stack then the 2nd and 3rd
parameters are the exception record and context record. Do a .cxr
on the 3rd parameter and then kb to obtain a more informative stack
trace.
Arguments:
Arg1: 001902fe
Arg2: f8af1590
Arg3: f8af128c
Arg4: f8409e28

Debugging Details:

EXCEPTION_RECORD: f8af1590 – (.exr 0xfffffffff8af1590)
ExceptionAddress: f8409e28 (Ntfs!NtfsWaitSync+0x0000001c)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 000000c6
Attempt to read from address 000000c6

CONTEXT: f8af128c – (.cxr 0xfffffffff8af128c)
eax=00000000 ebx=e1ae60d0 ecx=00000000 edx=80010031 esi=0000006e edi=00000000
eip=f8409e28 esp=f8af1658 ebp=f8af165c iopl=0 nv up ei ng nz na pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010287
Ntfs!NtfsWaitSync+0x1c:
f8409e28 8b4658 mov eax,dword ptr [esi+58h] ds:0023:000000c6=???
Resetting default scope

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

PROCESS_NAME: System

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

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

EXCEPTION_PARAMETER1: 00000000

EXCEPTION_PARAMETER2: 000000c6

READ_ADDRESS: 000000c6

FOLLOWUP_IP:
Ntfs!NtfsWaitSync+1c
f8409e28 8b4658 mov eax,dword ptr [esi+58h]

FAULTING_IP:
Ntfs!NtfsWaitSync+1c
f8409e28 8b4658 mov eax,dword ptr [esi+58h]

BUGCHECK_STR: 0x24

LAST_CONTROL_TRANSFER: from f840e7a2 to f8409e28

STACK_TEXT:
f8af165c f840e7a2 821baec8 81fbe980 821baec8 Ntfs!NtfsWaitSync+0x1c
f8af1824 f840aa6a 821baec8 81fbe980 e1ae60d0 Ntfs!NtfsNonCachedIo+0x43a
f8af1a1c f840ac18 821baec8 81fbe980 81fbe980 Ntfs!NtfsCommonWrite+0x1943
f8af1a80 804ee119 82383020 81fbe980 82372d10 Ntfs!NtfsFsdWrite+0xf3
f8af1a90 f84cb3ca 00000000 81fbe878 f8af1ad4 nt!IopfCallDriver+0x31
f8af1aa0 804ee119 823e5b38 e185b798 81fbe980 sr!SrWrite+0xaa
f8af1ab0 f84e0e9b 821f0388 81fbe980 822d48c0 nt!IopfCallDriver+0x31
f8af1ad4 f84e106b f8af1af4 821f0388 00000000 fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
f8af1b0c 804ee119 821f0388 81fbe980 806d1070 fltMgr!FltpDispatch+0x11f
f8af1b1c 80574d5e 81fbeb10 00000000 81fbe980 nt!IopfCallDriver+0x31
f8af1b30 8057284a 821f0388 81fbe980 82030ab0 nt!IopSynchronousServiceTail+0x70
f8af1be4 8053d638 80000758 800000dc 00000000 nt!NtWriteFile+0x602
f8af1be4 804ff311 80000758 800000dc 00000000 nt!KiFastCallEntry+0xf8
f8af1c80 806330b6 80000758 800000dc 00000000 nt!ZwWriteFile+0x11
f8af1cd4 8063220b 00001000 00000000 e31d3008 nt!CmpFileWrite+0x14c
f8af1d2c 806323df 00000012 e1a5eb60 80670c30 nt!HvpWriteLog+0x261
f8af1d40 80628bce e1a5eb01 8055b0fc 80550ca0 nt!HvSyncHive+0x71
f8af1d5c 80621a1b 00000000 823c48b8 00000000 nt!CmpDoFlushAll+0x6c
f8af1d74 80534c02 00000000 00000000 823c48b8 nt!CmpLazyFlushWorker+0x51
f8af1dac 805c6160 00000000 00000000 00000000 nt!ExpWorkerThread+0x100
f8af1ddc 80541dd2 80534b02 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: Ntfs!NtfsWaitSync+1c

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Ntfs

IMAGE_NAME: Ntfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 48025be5

STACK_COMMAND: .cxr 0xfffffffff8af128c ; kb

FAILURE_BUCKET_ID: 0x24_Ntfs!NtfsWaitSync+1c

BUCKET_ID: 0x24_Ntfs!NtfsWaitSync+1c

Followup: MachineOwner

Another execution and another crashdump output … :

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but …
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 804f9e8a, The address that the exception occurred at
Arg3: f5663728, Trap Frame
Arg4: 00000000

Debugging Details:

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

FAULTING_IP:
nt!KeWaitForSingleObject+2ea
804f9e8a c9 leave

TRAP_FRAME: f5663728 – (.trap 0xfffffffff5663728)
ErrCode = 00000000
eax=00000081 ebx=00000000 ecx=00000000 edx=f5663740 esi=82137300 edi=823e5b38
eip=804f9e8a esp=f566379c ebp=00000000 iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282
nt!KeWaitForSingleObject+0x2ea:
804f9e8a c9 leave
Resetting default scope

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0x8E

PROCESS_NAME: explorer.exe

LAST_CONTROL_TRANSFER: from 804f7b9d to 80527bdc

STACK_TEXT:
f5662ea4 804f7b9d 00000003 f5663200 00000000 nt!RtlpBreakWithStatusInstruction
f5662ef0 804f878a 00000003 00000000 f56636d4 nt!KiBugCheckDebugBreak+0x19
f56632d0 804f8cb5 0000008e c0000005 804f9e8a nt!KeBugCheck2+0x574
f56632f0 804fccef 0000008e c0000005 804f9e8a nt!KeBugCheckEx+0x1b
f56636b8 8053e081 f56636d4 00000000 f5663728 nt!KiDispatchException+0x3b1
f5663720 8053e032 00000000 804f9e8a badb0d00 nt!CommonDispatchException+0x4d
f566379c 804ee119 82383020 82137300 00000000 nt!KiExceptionExit+0x18a
f56637b0 f84ef7b7 00000000 00000000 00000000 nt!IopfCallDriver+0x31
f56637f0 f84f3252 823e5b38 8210fcf0 8219dbd4 fltMgr!FltpQueryInformationFile+0xa7
f5663820 f84f4062 822315d8 822315d8 f566384c fltMgr!FltpGetFileName+0x82
f5663830 f84f1c79 822315d8 00000000 822315d8 fltMgr!FltpGetOpenedFileName+0x18
f566384c f84f3dad 822315d8 00000000 820f86a8 fltMgr!FltpCallOpenedFileNameHandler+0x7f
f56638bc f84f3fe5 00000000 00000000 00000052 fltMgr!FltpExpandFilePathWorker+0x24d
f56638d4 f84f4129 820f86a8 00000000 820f86a8 fltMgr!FltpExpandFilePath+0x19
f56638f0 f84f476b 820f86a8 00000000 000000fe fltMgr!FltpGetNormalizedFileNameWorker+0x5f
f5663908 f84f22a2 820f86a8 00000000 820f86a8 fltMgr!FltpGetNormalizedFileName+0x19
f5663920 f84f2365 8054ada0 820f86a8 f566395c fltMgr!FltpCreateFileNameInformation+0x84
f5663930 f84e2e0a 820f86a8 821d2f5c 00000000 fltMgr!CreateTemporaryFileNameInformation+0xf
f566395c f84e3366 820f86a8 8200cbec 8200caa8 fltMgr!FltpGetFileNameInformation+0xaa
f5663984 f584d7be 001d2f5c 00000001 f566399c fltMgr!FltGetFileNameInformation+0x114
f56639a0 f84de888 821d2f5c f56639c0 f56639f0 cuckoo_minifilter!preCreateCallback+0x2e [e:\en_cours\cuckoo_minifilter\callbacks.c @ 16]
f5663a00 f84e02a0 00663a44 821d2f00 8201e198 fltMgr!FltpPerformPreCallbacks+0x2d4
f5663a14 f84ed217 f5663a44 f84eb6aa 00000000 fltMgr!FltpPassThroughInternal+0x32
f5663a2c f84ed742 f5663a44 82119f90 8201e018 fltMgr!FltpCreateInternal+0x63
f5663a60 804ee119 821b8bc0 8201e008 8201e008 fltMgr!FltpCreate+0x258
f5663a70 80578616 823868e8 8201e3dc f5663c18 nt!IopfCallDriver+0x31
f5663b50 805b4cbc 82386900 00000000 8201e338 nt!IopParseDevice+0xa12
f5663bd8 805b1065 00000000 f5663c18 00000040 nt!ObpLookupObjectName+0x56a
f5663c2c 8056b223 00000000 00000000 00000001 nt!ObOpenObjectByName+0xeb
f5663ca8 8056bb9a 0271e6e4 80100000 02bfeb38 nt!IopCreateFile+0x407
f5663d04 8056f3c1 0271e6e4 80100000 02bfeb38 nt!IoCreateFile+0x8e
f5663d44 8053d638 0271e6e4 80100000 02bfeb38 nt!NtOpenFile+0x27
f5663d44 7c90e4f4 0271e6e4 80100000 02bfeb38 nt!KiFastCallEntry+0xf8
02bfeb08 7c90d58c 7c81e499 0271e6e4 80100000 ntdll!KiFastSystemCallRet
02bfeb0c 7c81e499 0271e6e4 80100000 02bfeb38 ntdll!NtOpenFile+0xc
02bfeb7c 7c81e29c 000ea1a0 02bff508 000ea1a0 kernel32!BaseDllOpenIniFileOnDisk+0x1c4
02bfebb4 7c81e26e 000ea1a0 02bfed08 00000400 kernel32!BaseDllReadWriteIniFileOnDisk+0x22
02bfec98 7c81edce 00000001 00000000 00000001 kernel32!BaseDllReadWriteIniFile+0x175
02bfeccc 7c9f08ee 7c9c7004 02bfed08 00000400 kernel32!GetPrivateProfileSectionW+0x29
02bff714 7c9f083e 02bff744 00000000 02bff734 SHELL32!_GetFolderCLSID+0x75
02bff950 7c9ed99d 00000000 0273c428 0273d258 SHELL32!CFSFolder::_MarkAsJunction+0x72
02bffdb8 7c9f3cb1 0273d22c 00000000 02bffe20 SHELL32!CFSFolder::_CreateIDList+0x23c
02bffdd4 0100b97e 0273d008 00000001 02bffe20 SHELL32!CFileSysEnum::Next+0xc6
02bffe18 0100b69b 0273cfa8 00105e48 00000000 Explorer!CMenuItemsCache::_FillFolderCache+0x64
02bffe48 010081c1 00113c48 000d8d70 01007d9c Explorer!CMenuItemsCache::UpdateCache+0x16a
02bffe54 01007d9c 00113c48 01007d6b 00113c50 Explorer!ByUsage::EnumItems+0x39
02bffe5c 01007d6b 00113c50 02bffe84 01007ce9 Explorer!SFTBarHost::_EnumerateContentsBackground+0xa
02bffe68 01007ce9 00113c48 0012adc0 00120130 Explorer!SFTBarHost::CBGEnum::RunInitRT+0x11
02bffe84 75f81b9a 00113c48 75f81b18 75f80000 Explorer!CRunnableTask::Run+0x54
02bffee0 77f69588 000ec580 0273cfa8 77f6956b BROWSEUI!CShellTaskScheduler_ThreadProc+0x111
02bffef8 7c927aa2 0273cfa8 7c97b440 000fdac8 SHLWAPI!ExecuteWorkItem+0x1d
02bfff40 7c927ae3 77f6956b 0273cfa8 0009e510 ntdll!RtlpWorkerCallout+0x70
02bfff60 7c927ba5 00000000 0273cfa8 000fdac8 ntdll!RtlpExecuteWorkerRequest+0x1a
02bfff74 7c927b7c 7c927ac9 00000000 0273cfa8 ntdll!RtlpApcCallout+0x11
02bfffb4 7c80b713 00000000 00000000 00000000 ntdll!RtlpWorkerThread+0x87
02bfffec 00000000 7c910230 00000000 00000000 kernel32!BaseThreadStart+0x37

STACK_COMMAND: kb

FOLLOWUP_IP:
cuckoo_minifilter!preCreateCallback+2e [e:\en_cours\cuckoo_minifilter\callbacks.c @ 16]
f584d7be 8945f8 mov dword ptr [ebp-8],eax

FAULTING_SOURCE_CODE:
12: // monitored ?
13: if(!isProcessMonitoredByCallbackData(Data))
14: return FLT_PREOP_SUCCESS_NO_CALLBACK;
15:

16: status = FltGetFileNameInformation(Data,FLT_FILE_NAME_NORMALIZED,&ptrStructFileName);
17: if(status != STATUS_SUCCESS)
18: return FLT_PREOP_SUCCESS_NO_CALLBACK;
19: /*
20: if(isCuckooFile(ptrStructFileName->Name))
21: {

SYMBOL_STACK_INDEX: 14

SYMBOL_NAME: cuckoo_minifilter!preCreateCallback+2e

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: cuckoo_minifilter

IMAGE_NAME: cuckoo_minifilter.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 524a9a5d

FAILURE_BUCKET_ID: 0x8E_cuckoo_minifilter!preCreateCallback+2e

BUCKET_ID: 0x8E_cuckoo_minifilter!preCreateCallback+2e

Followup: MachineOwner

It doesn’t crash at the same place… that’s why I didn’t think it was usefull to send the crash log.

And weirdly, as I said above, If I just DbgPrint the datas without sending them to the named pipe (if I comment ZwWritefile), everything is working file and I don’t get any crashdump.

Is is really bad to use named pipe for that use???
Because here i just need to send data to the app, I don’t need to receive anything from the app.

Thanks !

5

What bother me with your solution is that I’ll have to do something like that in the user app :

while(1)
{
if(ReadFile(hComm, buf, 1024, &dwBytesRead, NULL))
{
WriteFile(hFile, buf, dwBytesRead, &dwBytesRead, NULL);
memset(buf, 0, sizeof(buf));
Sleep(100);
}
}

6

As Joe Newcomer indicated the normal way to do this is completing a request
(either read or IOCTL). The mechanism is known as inverted call, the last
NtInsider on the site hosting this list has an excellent article on this
mechanism. Another possibility is mini-filter communication ports since
this is a file system mini-filter, and that mechanism is for exactly what
you are doing.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Tuesday, October 01, 2013 6:18 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] BSOD minifilter driver when using named pipe with
userland app

Here is the analyze -v output :

****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

NTFS_FILE_SYSTEM (24)
If you see NtfsExceptionFilter on the stack then the 2nd and 3rd
parameters are the exception record and context record. Do a .cxr
on the 3rd parameter and then kb to obtain a more informative stack
trace.
Arguments:
Arg1: 001902fe
Arg2: f8af1590
Arg3: f8af128c
Arg4: f8409e28

Debugging Details:

EXCEPTION_RECORD: f8af1590 – (.exr 0xfffffffff8af1590)
ExceptionAddress: f8409e28 (Ntfs!NtfsWaitSync+0x0000001c)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 000000c6
Attempt to read from address 000000c6

CONTEXT: f8af128c – (.cxr 0xfffffffff8af128c)
eax=00000000 ebx=e1ae60d0 ecx=00000000 edx=80010031 esi=0000006e
edi=00000000
eip=f8409e28 esp=f8af1658 ebp=f8af165c iopl=0 nv up ei ng nz na pe
cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010287
Ntfs!NtfsWaitSync+0x1c:
f8409e28 8b4658 mov eax,dword ptr [esi+58h]
ds:0023:000000c6=???
Resetting default scope

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

PROCESS_NAME: System

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

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

EXCEPTION_PARAMETER1: 00000000

EXCEPTION_PARAMETER2: 000000c6

READ_ADDRESS: 000000c6

FOLLOWUP_IP:
Ntfs!NtfsWaitSync+1c
f8409e28 8b4658 mov eax,dword ptr [esi+58h]

FAULTING_IP:
Ntfs!NtfsWaitSync+1c
f8409e28 8b4658 mov eax,dword ptr [esi+58h]

BUGCHECK_STR: 0x24

LAST_CONTROL_TRANSFER: from f840e7a2 to f8409e28

STACK_TEXT:
f8af165c f840e7a2 821baec8 81fbe980 821baec8 Ntfs!NtfsWaitSync+0x1c
f8af1824 f840aa6a 821baec8 81fbe980 e1ae60d0 Ntfs!NtfsNonCachedIo+0x43a
f8af1a1c f840ac18 821baec8 81fbe980 81fbe980 Ntfs!NtfsCommonWrite+0x1943
f8af1a80 804ee119 82383020 81fbe980 82372d10 Ntfs!NtfsFsdWrite+0xf3
f8af1a90 f84cb3ca 00000000 81fbe878 f8af1ad4 nt!IopfCallDriver+0x31
f8af1aa0 804ee119 823e5b38 e185b798 81fbe980 sr!SrWrite+0xaa
f8af1ab0 f84e0e9b 821f0388 81fbe980 822d48c0 nt!IopfCallDriver+0x31
f8af1ad4 f84e106b f8af1af4 821f0388 00000000
fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
f8af1b0c 804ee119 821f0388 81fbe980 806d1070 fltMgr!FltpDispatch+0x11f
f8af1b1c 80574d5e 81fbeb10 00000000 81fbe980 nt!IopfCallDriver+0x31
f8af1b30 8057284a 821f0388 81fbe980 82030ab0
nt!IopSynchronousServiceTail+0x70
f8af1be4 8053d638 80000758 800000dc 00000000 nt!NtWriteFile+0x602
f8af1be4 804ff311 80000758 800000dc 00000000 nt!KiFastCallEntry+0xf8
f8af1c80 806330b6 80000758 800000dc 00000000 nt!ZwWriteFile+0x11
f8af1cd4 8063220b 00001000 00000000 e31d3008 nt!CmpFileWrite+0x14c f8af1d2c
806323df 00000012 e1a5eb60 80670c30 nt!HvpWriteLog+0x261
f8af1d40 80628bce e1a5eb01 8055b0fc 80550ca0 nt!HvSyncHive+0x71 f8af1d5c
80621a1b 00000000 823c48b8 00000000 nt!CmpDoFlushAll+0x6c
f8af1d74 80534c02 00000000 00000000 823c48b8 nt!CmpLazyFlushWorker+0x51
f8af1dac 805c6160 00000000 00000000 00000000 nt!ExpWorkerThread+0x100
f8af1ddc 80541dd2 80534b02 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: Ntfs!NtfsWaitSync+1c

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Ntfs

IMAGE_NAME: Ntfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 48025be5

STACK_COMMAND: .cxr 0xfffffffff8af128c ; kb

FAILURE_BUCKET_ID: 0x24_Ntfs!NtfsWaitSync+1c

BUCKET_ID: 0x24_Ntfs!NtfsWaitSync+1c

Followup: MachineOwner

Another execution and another crashdump output … :

****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
This is a very common bugcheck. Usually the exception address pinpoints the
driver/function that caused the problem. Always note this address as well
as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard coded
breakpoint or assertion was hit, but this system was booted /NODEBUG. This
is not supposed to happen as developers should never have hardcoded
breakpoints in retail code, but …
If this happens, make sure a debugger gets connected, and the system is
booted /DEBUG. This will let us see why this breakpoint is happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 804f9e8a, The address that the exception occurred at
Arg3: f5663728, Trap Frame
Arg4: 00000000

Debugging Details:

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

FAULTING_IP:
nt!KeWaitForSingleObject+2ea
804f9e8a c9 leave

TRAP_FRAME: f5663728 – (.trap 0xfffffffff5663728) ErrCode = 00000000
eax=00000081 ebx=00000000 ecx=00000000 edx=f5663740 esi=82137300
edi=823e5b38
eip=804f9e8a esp=f566379c ebp=00000000 iopl=0 nv up ei ng nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282
nt!KeWaitForSingleObject+0x2ea:
804f9e8a c9 leave
Resetting default scope

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0x8E

PROCESS_NAME: explorer.exe

LAST_CONTROL_TRANSFER: from 804f7b9d to 80527bdc

STACK_TEXT:
f5662ea4 804f7b9d 00000003 f5663200 00000000
nt!RtlpBreakWithStatusInstruction
f5662ef0 804f878a 00000003 00000000 f56636d4 nt!KiBugCheckDebugBreak+0x19
f56632d0 804f8cb5 0000008e c0000005 804f9e8a nt!KeBugCheck2+0x574
f56632f0 804fccef 0000008e c0000005 804f9e8a nt!KeBugCheckEx+0x1b
f56636b8 8053e081 f56636d4 00000000 f5663728 nt!KiDispatchException+0x3b1
f5663720 8053e032 00000000 804f9e8a badb0d00 nt!CommonDispatchException+0x4d
f566379c 804ee119 82383020 82137300 00000000 nt!KiExceptionExit+0x18a
f56637b0 f84ef7b7 00000000 00000000 00000000 nt!IopfCallDriver+0x31
f56637f0 f84f3252 823e5b38 8210fcf0 8219dbd4
fltMgr!FltpQueryInformationFile+0xa7
f5663820 f84f4062 822315d8 822315d8 f566384c fltMgr!FltpGetFileName+0x82
f5663830 f84f1c79 822315d8 00000000 822315d8
fltMgr!FltpGetOpenedFileName+0x18 f566384c f84f3dad 822315d8 00000000
820f86a8 fltMgr!FltpCallOpenedFileNameHandler+0x7f
f56638bc f84f3fe5 00000000 00000000 00000052
fltMgr!FltpExpandFilePathWorker+0x24d
f56638d4 f84f4129 820f86a8 00000000 820f86a8 fltMgr!FltpExpandFilePath+0x19
f56638f0 f84f476b 820f86a8 00000000 000000fe
fltMgr!FltpGetNormalizedFileNameWorker+0x5f
f5663908 f84f22a2 820f86a8 00000000 820f86a8
fltMgr!FltpGetNormalizedFileName+0x19
f5663920 f84f2365 8054ada0 820f86a8 f566395c
fltMgr!FltpCreateFileNameInformation+0x84
f5663930 f84e2e0a 820f86a8 821d2f5c 00000000
fltMgr!CreateTemporaryFileNameInformation+0xf
f566395c f84e3366 820f86a8 8200cbec 8200caa8
fltMgr!FltpGetFileNameInformation+0xaa
f5663984 f584d7be 001d2f5c 00000001 f566399c
fltMgr!FltGetFileNameInformation+0x114
f56639a0 f84de888 821d2f5c f56639c0 f56639f0
cuckoo_minifilter!preCreateCallback+0x2e
[e:\en_cours\cuckoo_minifilter\callbacks.c @ 16]
f5663a00 f84e02a0 00663a44 821d2f00 8201e198
fltMgr!FltpPerformPreCallbacks+0x2d4
f5663a14 f84ed217 f5663a44 f84eb6aa 00000000
fltMgr!FltpPassThroughInternal+0x32
f5663a2c f84ed742 f5663a44 82119f90 8201e018 fltMgr!FltpCreateInternal+0x63
f5663a60 804ee119 821b8bc0 8201e008 8201e008 fltMgr!FltpCreate+0x258
f5663a70 80578616 823868e8 8201e3dc f5663c18 nt!IopfCallDriver+0x31
f5663b50 805b4cbc 82386900 00000000 8201e338 nt!IopParseDevice+0xa12
f5663bd8 805b1065 00000000 f5663c18 00000040 nt!ObpLookupObjectName+0x56a
f5663c2c 8056b223 00000000 00000000 00000001 nt!ObOpenObjectByName+0xeb
f5663ca8 8056bb9a 0271e6e4 80100000 02bfeb38 nt!IopCreateFile+0x407
f5663d04 8056f3c1 0271e6e4 80100000 02bfeb38 nt!IoCreateFile+0x8e
f5663d44 8053d638 0271e6e4 80100000 02bfeb38 nt!NtOpenFile+0x27
f5663d44 7c90e4f4 0271e6e4 80100000 02bfeb38 nt!KiFastCallEntry+0xf8
02bfeb08 7c90d58c 7c81e499 0271e6e4 80100000 ntdll!KiFastSystemCallRet
02bfeb0c 7c81e499 0271e6e4 80100000 02bfeb38 ntdll!NtOpenFile+0xc 02bfeb7c
7c81e29c 000ea1a0 02bff508 000ea1a0 kernel32!BaseDllOpenIniFileOnDisk+0x1c4
02bfebb4 7c81e26e 000ea1a0 02bfed08 00000400
kernel32!BaseDllReadWriteIniFileOnDisk+0x22
02bfec98 7c81edce 00000001 00000000 00000001
kernel32!BaseDllReadWriteIniFile+0x175
02bfeccc 7c9f08ee 7c9c7004 02bfed08 00000400
kernel32!GetPrivateProfileSectionW+0x29
02bff714 7c9f083e 02bff744 00000000 02bff734 SHELL32!_GetFolderCLSID+0x75
02bff950 7c9ed99d 00000000 0273c428 0273d258
SHELL32!CFSFolder::_MarkAsJunction+0x72
02bffdb8 7c9f3cb1 0273d22c 00000000 02bffe20
SHELL32!CFSFolder::_CreateIDList+0x23c
02bffdd4 0100b97e 0273d008 00000001 02bffe20 SHELL32!CFileSysEnum::Next+0xc6
02bffe18 0100b69b 0273cfa8 00105e48 00000000
Explorer!CMenuItemsCache::_FillFolderCache+0x64
02bffe48 010081c1 00113c48 000d8d70 01007d9c
Explorer!CMenuItemsCache::UpdateCache+0x16a
02bffe54 01007d9c 00113c48 01007d6b 00113c50
Explorer!ByUsage::EnumItems+0x39 02bffe5c 01007d6b 00113c50 02bffe84
01007ce9 Explorer!SFTBarHost::_EnumerateContentsBackground+0xa
02bffe68 01007ce9 00113c48 0012adc0 00120130
Explorer!SFTBarHost::CBGEnum::RunInitRT+0x11
02bffe84 75f81b9a 00113c48 75f81b18 75f80000
Explorer!CRunnableTask::Run+0x54
02bffee0 77f69588 000ec580 0273cfa8 77f6956b
BROWSEUI!CShellTaskScheduler_ThreadProc+0x111
02bffef8 7c927aa2 0273cfa8 7c97b440 000fdac8 SHLWAPI!ExecuteWorkItem+0x1d
02bfff40 7c927ae3 77f6956b 0273cfa8 0009e510 ntdll!RtlpWorkerCallout+0x70
02bfff60 7c927ba5 00000000 0273cfa8 000fdac8
ntdll!RtlpExecuteWorkerRequest+0x1a
02bfff74 7c927b7c 7c927ac9 00000000 0273cfa8 ntdll!RtlpApcCallout+0x11
02bfffb4 7c80b713 00000000 00000000 00000000 ntdll!RtlpWorkerThread+0x87
02bfffec 00000000 7c910230 00000000 00000000 kernel32!BaseThreadStart+0x37

STACK_COMMAND: kb

FOLLOWUP_IP:
cuckoo_minifilter!preCreateCallback+2e
[e:\en_cours\cuckoo_minifilter\callbacks.c @ 16]
f584d7be 8945f8 mov dword ptr [ebp-8],eax

FAULTING_SOURCE_CODE:
12: // monitored ?
13: if(!isProcessMonitoredByCallbackData(Data))
14: return FLT_PREOP_SUCCESS_NO_CALLBACK;
15:

16: status =
FltGetFileNameInformation(Data,FLT_FILE_NAME_NORMALIZED,&ptrStructFileName);
17: if(status != STATUS_SUCCESS)
18: return FLT_PREOP_SUCCESS_NO_CALLBACK;
19: /*
20: if(isCuckooFile(ptrStructFileName->Name))
21: {

SYMBOL_STACK_INDEX: 14

SYMBOL_NAME: cuckoo_minifilter!preCreateCallback+2e

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: cuckoo_minifilter

IMAGE_NAME: cuckoo_minifilter.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 524a9a5d

FAILURE_BUCKET_ID: 0x8E_cuckoo_minifilter!preCreateCallback+2e

BUCKET_ID: 0x8E_cuckoo_minifilter!preCreateCallback+2e

Followup: MachineOwner

It doesn’t crash at the same place… that’s why I didn’t think it was
usefull to send the crash log.

And weirdly, as I said above, If I just DbgPrint the datas without sending
them to the named pipe (if I comment ZwWritefile), everything is working
file and I don’t get any crashdump.

Is is really bad to use named pipe for that use???
Because here i just need to send data to the app, I don’t need to receive
anything from the app.

Thanks !

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

7

http://msdn.microsoft.com/en-us/library/windows/hardware/ff539277(v=vs.85).aspx

I didn’t know about mini-filter communication ports ! Thanks I’m going to read the doc !

8

Thanks everybody, I implemented the mini-filter communication ports instead of the named pipes and it works like a charm !

9

>the userland app through named pipe :

Use the FltMgr’s communication ports instead. They are designed to do this.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com