Re[2]: KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)

> While debugging i found the problem is fileNameUnicodeString. Is

there any way to test it before passing it to
InitializeObjectAttributes ? Thanks for your time.

Looks like you are passing down a UNICODE_STRING with
Length = 0x1C and Buffer = NULL.

L.

See below…

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Tuesday, January 20, 2009 4:59 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)

Hi, I’m having trouble in spotting the culprit by the following analysis.Any
help in this regard would be of great help. The problem does not occur
always but once in a while on machines running JQS.exe (ie: JAVA) . By the
following analysis i figured our ESI is NULL,so it’s probably null pointer
deferencing causing this BSOD. I’m also pasting the source code that is
causing this error.Please point me where could be the problem in this
sourcecode the must be causing this error to happen very rarely. Thanks

1: kd> !analyze -v
****************************************************************************
***
*
*
* 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: 80574c44, The address that the exception occurred at
Arg3: f02dd578, 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!ObpCaptureObjectName+c6
80574c44 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]

TRAP_FRAME: f02dd578 – (.trap 0xfffffffff02dd578) ErrCode = 00000000
eax=e93fbda8 ebx=00000072 ecx=0000001c edx=00000072 esi=00000000
edi=e93fbda8
eip=80574c44 esp=f02dd5ec ebp=f02dd630 iopl=0 nv up ei pl nz na po
cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010203
nt!ObpCaptureObjectName+0xc6:
80574c44 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: JQS.EXE

LAST_CONTROL_TRANSFER: from 80529839 to 8053e832

STACK_TEXT:
f02dd140 80529839 0000008e c0000005 80574c44 nt!KeBugCheckEx+0x1b
f02dd508 804e5998 f02dd524 00000000 f02dd578 nt!KiDispatchException+0x3b1
f02dd570 804e5944 f02dd630 80574c44 badb0d00 nt!CommonDispatchException+0x4d
f02dd590 804e3b25 00000000 e9a6da88 00000000 nt!Kei386EoiHelper+0x18a
f02dd630 80574d25 00000000 f02dd8ec f02dd6b4 nt!ExReleaseResourceLite+0x8d
f02dd684 80578562 00000000 00000000 00000000
nt!ObpCaptureObjectCreateInformation+0x135
f02dd6c8 805864c3 f02dd8c4 00000000 00000000 nt!ObOpenObjectByName+0x62
f02dd744 80586592 f02dd8f4 00000080 f02dd8c4 nt!IopCreateFile+0x407 f02dd7a0
805865d5 f02dd8f4 00000080 f02dd8c4 nt!IoCreateFile+0x8e f02dd7e0 804e4f0f
f02dd8f4 00000080 f02dd8c4 nt!NtCreateFile+0x30 f02dd7e0 804ea9a5 f02dd8f4
00000080 f02dd8c4 nt!KiFastCallEntry+0xfc
f02dd884 f04a51a1 f02dd8f4 00000080 f02dd8c4 nt!ZwCreateFile+0x11
WARNING: Stack unwind information not available. Following frames may be
wrong.
f02dd918 f04a26e8 83928000 00000080 00000001 PPDrv+0x61a1 f02dda60 f04a3043
829f9ce0 8416c008 f02ddb60 PPDrv+0x36e8 f02dda70 804e89ee 829f9ce0 8416c008
8416c008 PPDrv+0x4043 f02dda80 80585eb8 843b5538 8380849c f02ddc18
nt!IopfCallDriver+0x31 f02ddb60 80575063 843b5550 00000000 838083f8
nt!IopParseDevice+0xa58
f02ddbd8 805785e8 00000000 f02ddc18 00000040 nt!ObpLookupObjectName+0x53c
f02ddc2c 805864c3 00000000 00000000 00000001 nt!ObOpenObjectByName+0xea
f02ddca8 80586592 00b4f430 00100020 00b4f3e8 nt!IopCreateFile+0x407
f02ddd04 80586740 00b4f430 00100020 00b4f3e8 nt!IoCreateFile+0x8e
f02ddd44 804e4f0f 00b4f430 00100020 00b4f3e8 nt!NtOpenFile+0x27
f02ddd44 7c90eb94 00b4f430 00100020 00b4f3e8 nt!KiFastCallEntry+0xfc
00b4f3b0 7c90dd09 7c916fec 00b4f430 00100020 ntdll!KiFastSystemCallRet
00b4f3b4 7c916fec 00b4f430 00100020 00b4f3e8 ntdll!NtOpenFile+0xc 00b4f67c
7c916042 00144038 00b4f6f4 00000000 ntdll!LdrpCheckForLoadedDll+0x42a
00b4f938 7c9162da 00000000 00144038 00b4fc2c ntdll!LdrpLoadDll+0x1ba
00b4fbe0 7c801bb9 00144038 00b4fc2c 00b4fc0c ntdll!LdrLoadDll+0x230
00b4fc48 7c801d6e 7ffdac00 00000000 00000001 kernel32!LoadLibraryExW+0x18e
00b4fc5c 00410266 003a74c0 00000000 00000001 kernel32!LoadLibraryExA+0x1f
00b4fdb4 00410ee8 003a73d0 003a73d0 00b4fe70 jqs+0x10266 00b4fdd0 004069b8
003a73d0 00000000 00000019 jqs+0x10ee8 00b4fe7c 00406b6f 003a73d0 01809501
0090eae0 jqs+0x69b8
00b4ff14 00406d1e 0090eae0 003a8138 003a4178 jqs+0x6b6f 00b4ff3c 00411db1
0000001e 00000001 0041d730 jqs+0x6d1e 00b4ff80 7c349565 00422e10 0090eae0
00000000 jqs+0x11db1
00b4ffb4 7c80b50b 003a4178 0090eae0 00000000 MSVCR71!_threadstartex+0x6f
[f:\vs70builds\3052\vc\crtbld\crt\src\threadex.c @ 241] 00b4ffec 00000000
7c3494f6 003a4178 00000000 kernel32!BaseThreadStart+0x37

STACK_COMMAND: kb

FOLLOWUP_IP:
PPDrv+61a1
f04a51a1 8945e0 mov dword ptr [ebp-20h],eax

SYMBOL_STACK_INDEX: c

SYMBOL_NAME: PPDrv+61a1

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: PPDrv

IMAGE_NAME: PPDrv.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 48999ea3

FAILURE_BUCKET_ID: 0x8E_PPDrv+61a1

BUCKET_ID: 0x8E_PPDrv+61a1

Followup: MachineOwner

1: kd> ~0
0: kd> kb
ChildEBP RetAddr Args to Child
0012f85c 77d487eb 73e68444 000e0408 00000229 USER32!InternalCallWinProc+0x2f
0012f8c4 77d4b743 00000000 73e68444 000e0408
USER32!UserCallWinProcCheckWow+0x150
0012f900 77d4e2f7 008f3a20 008f02f8 00000000 USER32!SendMessageWorker+0x4a5
0012f920 73de1e6f 000e0408 00000229 00000000 USER32!SendMessageA+0x7f
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012fa30 77d48564 006010d0 00000000 0012fae0 0x73de1e6f
0012fa44 ffffffff 0012fa6c 73dd1b9b 00000363 USER32!HMValidateHandle+0xae
0012fa48 0012fa6c 73dd1b9b 00000363 00000001 0xffffffff 0012fa4c 73dd1b9b
00000363 00000001 73e78830 0x12fa6c 0012fa6c 73dd2a10 00000363 00000001
00000000 0x73dd1b9b 0012fa8c 73dd1b05 00000363 00000001 00000000 0x73dd2a10
0012fb94 77d48bb1 7ffdf000 0012fbfc 77d48832 0x73dd1b05 0012fba0 77d48832
0012fbbc 77d487ff 00001004 USER32!_EndUserApiHook+0x11 0012fbfc 77d4b743
00000000 73e68444 000304fe USER32!UserCallWinProcCheckWow+0x170
0012fc38 77d4e2f7 009018a8 008f1910 00000000 USER32!SendMessageWorker+0x4a5
0012fc58 0051373b 000304fe 00001004 00000000 USER32!SendMessageA+0x7f
0012fdd4 77d48709 00050502 00008002 03a532d8 0x51373b 0012fe00 77d48bb1
7ffdf000 0012fe68 77d48832 USER32!InternalCallWinProc+0x28
0012fe68 77d489a5 00000000 73e68444 00050502 USER32!_EndUserApiHook+0x11
77d487ff 90909090 ffffff90 000000ff d7aa0500
USER32!DispatchMessageWorker+0x306
77d4880b d7aa0500 90909077 5d399090 391475e0 0x90909090
0: kd> ~1
1: kd> kb
ChildEBP RetAddr Args to Child
f02dd140 80529839 0000008e c0000005 80574c44 nt!KeBugCheckEx+0x1b
f02dd508 804e5998 f02dd524 00000000 f02dd578 nt!KiDispatchException+0x3b1
f02dd570 804e5944 f02dd630 80574c44 badb0d00 nt!CommonDispatchException+0x4d
f02dd590 804e3b25 00000000 e9a6da88 00000000 nt!Kei386EoiHelper+0x18a
f02dd630 80574d25 00000000 f02dd8ec f02dd6b4 nt!ExReleaseResourceLite+0x8d
f02dd684 80578562 00000000 00000000 00000000
nt!ObpCaptureObjectCreateInformation+0x135
f02dd6c8 805864c3 f02dd8c4 00000000 00000000 nt!ObOpenObjectByName+0x62
f02dd744 80586592 f02dd8f4 00000080 f02dd8c4 nt!IopCreateFile+0x407 f02dd7a0
805865d5 f02dd8f4 00000080 f02dd8c4 nt!IoCreateFile+0x8e f02dd7e0 804e4f0f
f02dd8f4 00000080 f02dd8c4 nt!NtCreateFile+0x30 f02dd7e0 804ea9a5 f02dd8f4
00000080 f02dd8c4 nt!KiFastCallEntry+0xfc
f02dd884 f04a51a1 f02dd8f4 00000080 f02dd8c4 nt!ZwCreateFile+0x11
WARNING: Stack unwind information not available. Following frames may be
wrong.
f02dd918 f04a26e8 83928000 00000080 00000001 PPDrv+0x61a1 f02dda60 f04a3043
829f9ce0 8416c008 f02ddb60 PPDrv+0x36e8 f02dda70 804e89ee 829f9ce0 8416c008
8416c008 PPDrv+0x4043 f02dda80 80585eb8 843b5538 8380849c f02ddc18
nt!IopfCallDriver+0x31 f02ddb60 80575063 843b5550 00000000 838083f8
nt!IopParseDevice+0xa58
f02ddbd8 805785e8 00000000 f02ddc18 00000040 nt!ObpLookupObjectName+0x53c
f02ddc2c 805864c3 00000000 00000000 00000001 nt!ObOpenObjectByName+0xea
f02ddca8 80586592 00b4f430 00100020 00b4f3e8 nt!IopCreateFile+0x407
1: kd> .trap f02dd578
ErrCode = 00000000
eax=e93fbda8 ebx=00000072 ecx=0000001c edx=00000072 esi=00000000
edi=e93fbda8
eip=80574c44 esp=f02dd5ec ebp=f02dd630 iopl=0 nv up ei pl nz na po
cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010203
nt!ObpCaptureObjectName+0xc6:
80574c44 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
1: kd> !kbvs=f02dd630 f02dd5ec 80574c44 No export kbvs=f02dd630 found

Source Code

HANDLE Async_open ( char *fullPathName, ACCESS_MASK DesiredAccess, unsigned
long CreateDisposition )
{
OBJECT_ATTRIBUTES objectAttributes ;
HANDLE ntFileHandle;
// char gRZFileName
[MAXPATHLEN+10] ;
char *gRZFileName
= NULL ;
ANSI_STRING FileNameString ;
UNICODE_STRING fileNameUnicodeString;
NTSTATUS ntStatus ;
IO_STATUS_BLOCK ioStatus ;

gRZFileName = (char *)AllocateBuffer ( MAXPATHLEN );
//-OurAllocMem_MAXPATHLEN ( );

if ( gRZFileName )
{
if ( (fullPathName [0] == ‘\’) && (fullPathName [1] ==
‘\’) )
{
strcpy ( gRZFileName, “\??\UNC” ) ;
strcat ( gRZFileName, fullPathName + 1 ) ;
***************************************************************
At this point I pretty much stopped reading. There are so many errors here.
Why are you using a char * in the kernel? You are at this point in such
deep trouble that nothing beyond this point is worth worrying about. The
kernel runs in Unicode.

Convert this to use Unicode.

Strcpy and strcat have been deprecated because they are security hazards.
You are building a string in a buffer whose size you have not provided any
bounds-check on. There are no explicit bounds checks you have written to
assure there is no buffer overrun. This is exceptionally poor practice by
modern standards (and a firable offense in some companies these days!) It
is a security violation. In user space, it is considered amateur
programming these days; in kernel space, it is irresponsible.

Then you convert the filename to uppercase, which is a questionable
practice.

The only way to salvage this mess is to rewrite it in Unicode, using
appropriate secure string functions, preferrably using UNICODE_STRING.

As I often say in another newsgroup devoted to MFC, “‘char’ is an obsolete
data type to be used only in rare and exotic situations. This is not one of
them.” It applies even more so in the kernel. The only place char is used
is for debug-print strings. And you can use %ls to print a Unicode string
(note that it does down-convert, so if the filename were in Japanese it
would come out with ‘?’ for all the characters that do not convert).

Why did you specify “unsigned long” instead of the more common “ULONG”?
This suggests a first-time kernel programmer.

I would not have returned -1, but there is a symbol INVALID_HANDLE_VALUE
which is defined as a handle-cast of -1. I’d look for this equivalent in
the kernel symbols. If not, I would define it.

By tradition, the ‘g’ prefix indicates a global variable, yet you declared a
local variable starting with ‘g’. Then you initialize it to a fixed size,
“MAXPATHLEN”. If you were going to initialize to any length, it would be
the length of the input string plus the length of the things you are adding
plus 1 for the terminal NUL character (which you shouldn’t be worrying about
anyway because typically strings are not NUL-terminated in the kernel, hence
the use of UNICODE_STRING)

Kernel programming is not user-mode programming. This would be an
exceptionally poor example of user-mode programming, and it is a truly
abysmal example of kernel programming.

Frankly, I would not waste any effort trying to debug this. Rewrite it so
it makes sense and is secure. Then, if it still crashes, worry about
debugging it.
*****************************************************************

}
else if ( fullPathName [1] == ‘:’ )
{
strcpy ( gRZFileName, “\??\” ) ;
strcat ( gRZFileName, fullPathName ) ;
}
else
strcpy ( gRZFileName, fullPathName ) ;

strcat ( gRZFileName, “$#DRV%$” );
Ourstrupr ( fullPathName );
RtlInitAnsiString ( &FileNameString, gRZFileName ) ;
RtlAnsiStringToUnicodeString ( &fileNameUnicodeString,
&FileNameString, TRUE ) ;

InitializeObjectAttributes ( &objectAttributes,
&fileNameUnicodeString, \

OBJ_CASE_INSENSITIVE, NULL, NULL ) ;

try
{
DbgPrint ( ( “ZwCreateFile - Async - start - %s”,
fullPathName ) );
DbgPrint ( ( “\n” ) );

ntStatus = ZwCreateFile ( &ntFileHandle,

DesiredAccess,

&objectAttributes,

&ioStatus,

NULL,

FILE_ATTRIBUTE_NORMAL,

FILE_SHARE_READ | FILE_SHARE_WRITE,

CreateDisposition,

FILE_SYNCHRONOUS_IO_ALERT | FILE_NON_DIRECTORY_FILE,

NULL,

0 );

DbgPrint ( ( “ZwCreateFile - Async - end - %s”,
fullPathName ) );
DbgPrint ( ( “\n” ) );
}
except ( EXCEPTION_EXECUTE_HANDLER )
{
}

RtlFreeUnicodeString ( &fileNameUnicodeString ) ;
if ( !NT_SUCCESS ( ntStatus ) )
{
if ( gRZFileName )
FreeBuffer ( gRZFileName, MAXPATHLEN );
//-OurfreeMem_MAXPATHLEN ( gRZFileName );
return -1 ;
}
}
else
return -1 ;

if ( gRZFileName )
FreeBuffer ( gRZFileName, MAXPATHLEN );
//-OurfreeMem_MAXPATHLEN ( gRZFileName );
return ntFileHandle ;
}


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: xxxxx@flounder.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Thx very much Joseph . This is a mess created by previous programmers which i have to clear. I will re-write this module to use UNICODE_STRING. Thanks once again.