BSOD in RtlStringCbCatExW on CPU 1

NTFSD
1

NTFSD Folk:

I’ve got a strange BSOD (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)) on an XP SP2 system where a worker thread (FLT_GENERIC_WORKITEM)
used RtlStringCbCatExW().

The routine is converting SIDs to a Unicode string. It’s worked for months and this is the first crash. Here’s a code snippet:

// iBytes is 0xF20 (3,872) in the crash dump
iBytes = ( SID_MAX_SUB_AUTHORITIES * 10 + 2 + 10 + 10 + 4 ) * NumSIDs * sizeof(WCHAR);
pSIDString = ExAllocatePoolWithTag( PagedPool, iBytes, ‘ssKF’ );
if( NULL == pSIDString ) return NULL;

… Copy some stuff to pSIDString, about 30 chars

// Here’s the crash…
RtlStringCbCatExW( pSIDString, iBytes, L",", NULL, NULL, 0 );

Since it’s a generic work item, it’s guaranteed to be running at IRQL PASSIVE_LEVEL, so allocating from PagedPool shouldn’t be a
problem. In the crash dump, pSIDString was pointing to valid memory.

However, I noticed that the crash was on CPU 1 (it’s a dual-processor core). Here’s the call stack on CPU 1:

fkdriver!RtlStringLengthWorkerW+0x1c
fkdriver!RtlStringValidateDestW+0x2d
fkdriver!RtlStringExValidateDestW+0x61
fkdriver!RtlStringCbCatExW+0x2f
fkdriver!FKBuildSIDListString+0xba
fkdriver!FKSendToFKService+0xa5
fkdriver!FKDriverPostSetInfoFinish+0x3e
fltMgr!FltpProcessGenericWorkItem+0x14

There shouldn’t be any problem sharing PagedPool between processors at IRQL PASSIVE_LEVEL, should there? Could some context switch
down in RtlStringxxx cause it to be at higher IRQL?

Thanks,
Ken

2

> I’ve got a strange BSOD (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)) on an XP SP2 system where a worker thread (FLT_GENERIC_WORKITEM)> used RtlStringCbCatExW().
What was the exception code that was not handled for this stop? The unhandled exception code should be parameter one for the bugcheck code. What is the reproduction scenario for this stop?

There shouldn’t be any problem sharing PagedPool between processors at IRQL PASSIVE_LEVEL, should there? Could some context switch> down in RtlStringxxx cause it to be at higher IRQL?
According to the MSDN docs for RtlStringCbCatEx,

"RtlStringCbCatExW and RtlStringCbCatExA should be used instead of the following functions: strcat, wcscat "
“Callers of RtlStringCbCatExW and RtlStringCbCatExA must be running at IRQL = PASSIVE_LEVEL”.

I know that strcat and wcscat can be used safely on memory located in the paged pool, and if it’s proscribing you from calling this method from anything higher than passive level then it really suggests that it’s safe to call it with paged memory in all cases. There is really no reason to believe that this method attempts to access any of its inputs at an elevated IRQL.

Help yourself to FREE treats served up daily at the Messenger Caf?. Stop by today.
http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline

3

Jason:

The exception code is the usual:

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
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.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: a1859101, The address that the exception occurred at
Arg3: ba51b6c4, Exception Record Address
Arg4: ba51b3c0, Context Record Address

Debugging Details:

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

I can?t reproduce it since it?s been running OK for months and continued to run fine on that system after it restarted.

One strange thing, though (maybe due to the multi-processor environment) is that the stack dump from ?!analyze ?v? is different from
the call stack.

From !analyze ?v:

STACK_TEXT:
ba51b798 a1859a19 00000043 88649598 00000000 fkdriver!write_string+0x21 [d:\vistartm\base\crts\crtw32\stdio\output.c @ 2783]
ba51bc04 a1858610 ba51bc28 a185b37c 00000000 fkdriver!_woutput_l+0x8e3 [d:\vistartm\base\crts\crtw32\stdio\output.c @ 2491]
ba51bc48 a1858670 88649598 0000014c a185b348 fkdriver!_vsnwprintf_l+0x7b [d:\vistartm\base\crts\crtw32\stdio\vswprint.c @ 189]
ba51bc64 a1858214 88649598 0000014c a185b348 fkdriver!_vsnwprintf+0x18 [d:\vistartm\base\crts\crtw32\stdio\vswprint.c @ 261]
ba51bc88 a18498bd 88649598 0000014d 00000000 fkdriver!RtlStringVPrintfWorkerW+0x1e [d:\vistartm.public.x86fre\ddk\inc\ntstrsafe.h @
11795]
ba51bca8 a185110a 88649598 0000029a a185b348 fkdriver!RtlStringCbPrintfW+0x31 [d:\nh\winddk\inc\ddk\ntstrsafe.h @ 4497]
ba51bd08 a1848b10 a1859d38 865339c8 8794c428 fkdriver!FKSendToFKService+0x44c [d:\nh\filekeeper\fkdriver\fkdriver\fklib.c @ 1698]
ba51bd64 b9e0ca88 8794c428 888f2d1c 865339c8 fkdriver!FKDriverPostCleanupFinish+0x1fe [d:\nh\filekeeper\fkdriver\fkdriver\fkdriver.c
@ 2470]
ba51bd7c 805379bd 8794c428 00000000 8a0603c8 fltMgr!FltpProcessDeferredIoWorkItem+0x16

From the call stack for CPU 1:

fkdriver!RtlStringLengthWorkerW+0x1c
fkdriver!RtlStringValidateDestW+0x2d
fkdriver!RtlStringExValidateDestW+0x61
fkdriver!RtlStringCbCatExW+0x2f
fkdriver!FKBuildSIDListString+0xba
fkdriver!FKSendToFKService+0xa5
fkdriver!FKDriverPostSetInfoFinish+0x3e
fltMgr!FltpProcessGenericWorkItem+0x14

The call stack for CPU 0 is virtually empty:

nt!KeBugCheckEx+0x1b
nt!PspUnhandledExceptionInSystemThread+0x1a
nt!PspSystemThreadStartup+0x5a
nt!PspSystemThreadStartup+0x5a

Ken

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jason Sanchez
Sent: Thursday, November 01, 2007 8:29 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] BSOD in RtlStringCbCatExW on CPU 1

I’ve got a strange BSOD (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)) on an XP SP2 system where a worker thread
(FLT_GENERIC_WORKITEM)
used RtlStringCbCatExW().?

What was the exception code that was not handled for this stop?? The unhandled exception code should be parameter one for the
bugcheck code.? What is the reproduction scenario for this stop?
?

There shouldn’t be any problem sharing PagedPool between processors at IRQL PASSIVE_LEVEL, should there? Could some context switch
down in RtlStringxxx cause it to be at higher IRQL?

According to the MSDN docs for RtlStringCbCatEx,
?
"RtlStringCbCatExW and RtlStringCbCatExA should be used instead of the following functions: strcat, wcscat "
“Callers of RtlStringCbCatExW and RtlStringCbCatExA must be running at IRQL = PASSIVE_LEVEL”.
?
I know that strcat and wcscat can be used safely on memory located in the paged pool, and if it’s proscribing you from calling this
method from anything higher than passive level then it really suggests that it’s safe to call it with paged memory in all cases.?
There is really no reason to believe that this method attempts to access any of its inputs at an elevated IRQL.

Help yourself to FREE treats served up daily at the Messenger Caf?. Stop by today!

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

>The call stack for CPU 0 is virtually empty:

nt!KeBugCheckEx+0x1b
nt!PspUnhandledExceptionInSystemThread+0x1a
nt!PspSystemThreadStartup+0x5a
nt!PspSystemThreadStartup+0x5a

It is not empty is is BSOD!!! So BSOD is not caused by thread running on CPU1, but on CPU0.

Arg3: ba51b6c4, Exception Record Address
Arg4: ba51b3c0, Context Record Address

Take look on .cxr windbg command

Still didn’t get? The BSOD is caused by fkdriver!RtlStringCbPrintf() function so analyze stack. By this way you get format string parameter (pszFormat), so you can locate where it is in your code. After that carefully analyze parameters, which are you passing behind pszFormat. You are probably passing some invalid pointer which is then dereferenced by formatter.

Good luck!
-bg