RE: RtlStringC?bVPrintfA with %wZ formatting directive for non-Englis?h UNICODE_ST?RING

It would appear that you have done exactly what the bugcheck says,
referenced memory after you’ve released it. The string buffer appears to
have been a file path that has been overwritten by several pointers. Where
do you get the memory referenced in the Buffer member in your
UNICODE_STRING?

You’ve done really well to paste the !analyze -v, and your investigation has
been pretty good, as far as it goes. If you haven’t figured it out by now,
you might want to post the routine that’s calling RtlStringCbVPrintfA. If
you are reluctant to post the entire routine, at the very least, post the
call and ***every*** reference to the parameters passed into the call.

Phil

Philip D. Barila??? (303) 776-1264

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Monday, February 28, 2011 2:02 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] RtlStringC?bVPrintfA with %wZ formatting directive for
non-Englis?h UNICODE_ST?RING

I recently got a 0xD5 BSOD with my minifilter on Windows 7 professional. I
am wondering if there is a bug in the RtlStringCbVPrintfA API when
specifying %wZ formatting directive for non-English UNICODE_STRING. Here is
the OS info and “!analyze -v” output.

1: kd> vertarget
Windows 7 Kernel Version 7600 MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16617.x86fre.win7_gdr.100618-1621
Machine Name:
Kernel base = 0x83456000 PsLoadedModuleList = 0x8359e810
Debug session time: Mon Feb 28 02:25:03.864 2011 (UTC - 5:00)
System Uptime: 0 days 0:28:34.726

1: kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL (d5)
Memory was referenced after it was freed.
This cannot be protected by try-except.
When possible, the guilty driver’s name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: e5010fe8, memory referenced
Arg2: 00000000, value 0 = read operation, 1 = write operation
Arg3: 8429777b, if non-zero, the address which referenced memory.
Arg4: 00000000, (reserved)

Debugging Details:

READ_ADDRESS: e5010fe8 Special pool

FAULTING_IP:
MyDriver!_output_l+815 [d:\winmain\minkernel\crts\crtw32\stdio\output.c @
2449]
8429777b 0fb703 movzx eax,word ptr [ebx]

MM_INTERNAL_CODE: 0

IMAGE_NAME: MyDriver.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d6495b7

MODULE_NAME: MyDriver

FAULTING_MODULE: 84292000 MyDriver

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xD5

PROCESS_NAME: explorer.exe

CURRENT_IRQL: 0

TRAP_FRAME: b3e4d3c8 – (.trap 0xffffffffb3e4d3c8)
ErrCode = 00000000
eax=00000049 ebx=e5010fe8 ecx=00000000 edx=e50d4c85 esi=ffffffd1
edi=b3e4d6bc
eip=8429777b esp=b3e4d43c ebp=b3e4d698 iopl=0 nv up ei pl nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010202
MyDriver!_output_l+0x815:
8429777b 0fb703 movzx eax,word ptr [ebx]
ds:0023:e5010fe8=???
Resetting default scope

LAST_CONTROL_TRANSFER: from 8349c638 to 834db903

STACK_TEXT:
b3e4d3b0 8349c638 00000000 e5010fe8 00000000 nt!MmAccessFault+0x106
b3e4d3b0 8429777b 00000000 e5010fe8 00000000 nt!KiTrap0E+0xdc
b3e4d698 84296e4d b3e4d6bc 84297ff4 00000000 MyDriver!_output_l+0x815
[d:\winmain\minkernel\crts\crtw32\stdio\output.c @ 2449]
b3e4d6dc 84296e92 e50d4c05 000003f9 84297fb6 MyDriver!_vsnprintf_l+0x72
[d:\winmain\minkernel\crts\crtw32\stdio\vsprintf.c @ 185]
b3e4d6f8 84296da8 e50d4c05 000003f9 84297fb6 MyDriver!_vsnprintf+0x18
[d:\winmain\minkernel\crts\crtw32\stdio\vsprintf.c @ 237]
b3e4d71c 84295942 e50d4c05 000003fa 00000000
MyDriver!RtlStringVPrintfWorkerA+0x1e
[d:\5359.public.x86fre\ddk\inc\ntstrsafe.h @ 11872]
b3e4d738 842959d3 e50d4c05 000003fa 84297fb6
MyDriver!RtlStringCbVPrintfA+0x2c
[d:\winddk\7600.16385.1\inc\ddk\ntstrsafe.h @ 4274]
b3e4d77c 84295a9a b3e4d7a0 84297f40 00000006
MyDriver!DebugMessageToStringSafe+0x87
b3e4d818 842857d1 8ff27e40 b3e4d86c 00000000 MyDriver!PostWrite+0x52
b3e4d848 84260324 8ff27e40 00e4d86c 00000000 fltmgr!FltvPostOperation+0x71
b3e4d8b0 84263512 00f27de0 8ff27de0 10000004
fltmgr!FltpPerformPostCallbacks+0x24a
b3e4d8c4 84263b46 8ff27de0 b3e4d978 b3e4d904
fltmgr!FltpProcessIoCompletion+0x10
b3e4d8d4 83785cd4 8ac68378 e5324d28 8ff27de0
fltmgr!FltpPassThroughCompletion+0x98
b3e4d904 834beb33 8ac68378 e5324d28 b3e4d978
nt!IovpLocalCompletionRoutine+0x14b
b3e4d948 83785b64 90e07e28 92abe900 00000000 nt!IopfCompleteRequest+0x128
b3e4d9b0 8babdc77 b3e4dae4 8bacc16d 92abe900 nt!IovCompleteRequest+0x133
b3e4d9b8 8bacc16d 92abe900 e5324d28 00000000
fastfat!FatCompleteRequest_Real+0x49
b3e4d9c8 8bacc0b8 384e296a 92abe900 e5324d28 fastfat!FatCommonWrite+0x1449
b3e4dae4 8baabead 92abe900 e5324d28 384e28a2 fastfat!FatCommonWrite+0x1394
b3e4db2c 837856c3 87de9ae0 e5324d28 00000000 fastfat!FatFsdWrite+0xb3
b3e4db50 83492473 00000000 e5324d28 87de9ae0 nt!IovCallDriver+0x258
b3e4db64 8426420c 8ac68378 e5324d28 00000000 nt!IofCallDriver+0x1b
b3e4db88 842643cb b3e4dba8 8ac68378 00000000
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2aa
b3e4dbc0 837856c3 8ac68378 e5324d28 a9c0ad38 fltmgr!FltpDispatch+0xc5
b3e4dbe4 83492473 00000000 e5324d28 8ac68378 nt!IovCallDriver+0x258
b3e4dbf8 842fd4a4 b3e4dc14 842fd802 8ac684c0 nt!IofCallDriver+0x1b
WARNING: Stack unwind information not available. Following frames may be
wrong.
b3e4dc38 83492473 00000000 e5324d28 8ac684c0 nt!IovCallDriver+0x258
b3e4dc4c 83693f6e 90e07e28 e5324d28 e5324fd8 nt!IofCallDriver+0x1b
b3e4dc6c 83694822 8ac684c0 90e07e28 00000001
nt!IopSynchronousServiceTail+0x1f8
b3e4dd08 8349944a 8ac684c0 00000fdc 00000000 nt!NtWriteFile+0x6e8
b3e4dd08 778964f4 8ac684c0 00000fdc 00000000 nt!KiFastCallEntry+0x12a
063cd7d4 00000000 00000000 00000000 00000000 0x778964f4

STACK_COMMAND: kb

FOLLOWUP_IP:
MyDriver!_output_l+815 [d:\winmain\minkernel\crts\crtw32\stdio\output.c @
2449]
8429777b 0fb703 movzx eax,word ptr [ebx]

FAULTING_SOURCE_CODE:
No source found for ‘d:\winmain\minkernel\crts\crtw32\stdio\output.c’

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: MyDriver!_output_l+815

FOLLOWUP_NAME: MachineOwner

FAILURE_BUCKET_ID: 0xD5_VRF_MyDriver!_output_l+815

BUCKET_ID: 0xD5_VRF_MyDriver!_output_l+815

Followup: MachineOwner

Here is the format that I specified for RtlStringCbVPrintfA, “Write
(Process: %wZ) 0x%x bytes at offset 0x%I64x to file: %wZ”. And here is the
argList, 0xb3e4d7b4. Look at the following.

1: kd> dd 0xb3e4d7b4
b3e4d7b4 b3e4d7dc 00010000 00000000 00000000
b3e4d7c4 b63f6134 b3e4d86c 8ff27e40 b3e4d86c
b3e4d7d4 00000000 00000000 00180018 e5004fe0
b3e4d7e4 00000000 b5018190 b63f6128 00000000
b3e4d7f4 b3e4d818 842967e4 01f27e40 b3e4d86c
b3e4d804 00010000 00000000 00000000 8c1880f4
b3e4d814 834246ee b3e4d848 842857d1 8ff27e40
b3e4d824 b3e4d86c 00000000 00000000 8ff27f70

1: kd> dt _UNICODE_STRING b3e4d7dc
hal!_UNICODE_STRING
“explorer.exe”
+0x000 Length : 0x18
+0x002 MaximumLength : 0x18
+0x004 Buffer : 0xe5004fe0 “explorer.exe”
1: kd> dt _UNICODE_STRING b63f6134
hal!_UNICODE_STRING
“F:?????????????????????\IMG_0017.JPG”
+0x000 Length : 0x5e
+0x002 MaximumLength : 0x5e
+0x004 Buffer : 0xe50fcfa0
“F:?????????????????????\IMG_0017.JPG”

1: kd> !pool 0xe50fcfa0
Pool page e50fcfa0 region is Special pool
*e50fc000 size: 60 data: e50fcfa0 (Paged) *RDfn
Owning component : Unknown (update pooltag.txt)

1: kd> dW 0xe50fcfa0
e50fcfa0 0046 003a 005c 4f1a 8a08 8ab2 005c 7ba1 F.:...O…..{
e50fcfb0 8ca1 4fc2 9577 005c 65bd 8a2d 5199 771f …Ow...e-…Q.w
e50fcfc0 005c 798f 5ca1 005c 798f 5ca1 69cb 5185 ..y.\…y..i.Q
e50fcfd0 6df7 96d1 72b6 6cc1 005c ff13 6708 ff12 .m…r.l.…g…
e50fcfe0 ff17 65e5 005c 0049 004d 0047 005f 0030 …e.I.M.G._.0.
e50fcff0 0030 0031 0037 002e 004a 0050 0047 5d5d 0.1.7…J.P.G.]]
e50fd000 ??? ??? ??? ??? ??? ??? ??? ??? ???
e50fd010 ??? ??? ??? ??? ??? ??? ??? ??? ???

I can not figure out what is wrong at here. Anyone met the same problem
before? Can I specify ‘%wZ’ as the formatting parameter for non-English
UNICODE_STRING? Thanks.


NTFSD is sponsored by OSR

For our schedule of debugging and file system 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