This is WinXP Bug?

I test the USB device(e.g.USB Mouse).I found when i plug and plug about
1000 times can result in BSOD.

I found RtlInitUnicodeString access memory violation.How can i resolve this
problem.Who can explain What reason result in BSOD?

Following is BugCheck analysis.

*******************************************************************************
*
*
* 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: 8052e77f, The address that the exception occurred at
Arg3: aa8c23f8, Trap Frame
Arg4: 00000000

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - “0x%08lx”

FAULTING_IP:
nt!RtlInitUnicodeString+1b
8052e77f f266af repne scasw

TRAP_FRAME: aa8c23f8 – (.trap ffffffffaa8c23f8)
ErrCode = 00000000
eax=00000000 ebx=f9a0a720 ecx=ffffffee edx=aa8c24ac esi=00c6e7a8
edi=0016b000
eip=8052e77f esp=aa8c246c ebp=aa8c2d30 iopl=0 nv up ei pl zr na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
nt!RtlInitUnicodeString+0x1b:
8052e77f f266af repne scasw es:0016b000
=???
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

LAST_CONTROL_TRANSFER: from 8053c4f4 to 8052e77f

STACK_TEXT:
aa8c24bc 8053c4f4 00000000 00000000 00000000 nt!RtlInitUnicodeString+0x1b
aa8c2d30 8054160c 00000528 00000000 00000000 nt!_flsbuf+0xa3
aa8c2d30 7c92eb94 00000528 00000000 00000000 nt!KiFastCallEntry+0xfc
00c6e770 7c92df6a 7c80f26f 00000528 00000000 ntdll!KiFastSystemCallRet
00c6e774 7c80f26f 00000528 00000000 00000000 ntdll!ZwQueryDirectoryFile+0xc
00c6e7f0 760b7362 000c3978 00c6e87c 00000000 kernel32!FindNextFileW+0xaa
00c6ead0 760b758f 000c4898 00031d00 00092fa8
setupapi!InfCacheSearchDirectory+0x470
00c6eb04 760a72d9 000c4898 00031d00 00092fa8
setupapi!InfCacheSearchPath+0x52
00c6eba4 76083e4e 00000000 00000005 76082349
setupapi!EnumDrvInfsInDirPathList+0x262
00c6f3b4 7e1f01d9 000b64a0 00c6fcf4 00000002
setupapi!SetupDiBuildDriverInfoList+0x9a7
00c6ff1c 7e1e9a76 00d412e0 7e1fa1dc 00c6ff64
umpnpmgr!InstallDeviceServerSide+0x144
00c6ffb4 7c80b50b 00000000 7c9363a8 00c2feb8
umpnpmgr!ThreadProc_DeviceInstall+0x449
00c6ffec 00000000 7e1e5dbf 00000000 00000000 kernel32!BaseThreadStart+0x37

FOLLOWUP_IP:
nt!_flsbuf+a3
8053c4f4 43 inc ebx

SYMBOL_STACK_INDEX: 1

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!_flsbuf+a3

MODULE_NAME: nt

IMAGE_NAME: ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 42250a1e

STACK_COMMAND: .trap ffffffffaa8c23f8 ; kb

FAILURE_BUCKET_ID: 0x8E_nt!_flsbuf+a3

BUCKET_ID: 0x8E_nt!_flsbuf+a3

Followup: MachineOwner

=========================================================================================================

Best Regards
Ken Wang

And are you still hooking ZwQueryDirectoryFile? If so, I would say your hook
is at fault.

Have you ran performance monitor and taken a look for memory leaks?
RtlInitUnicodeString requires two buffers; one to contain the UNICODE_STRING
structure and one to contain the actual string. Are both of those being
released?

What is your IRQL? The C0000005 says access denied and that could be caused
by being at DISPATCH_LEVEL and accessing paged memory.

As asked in another thread, and which I never saw your answer, is
SourceString a NULL terminated string?

Did you perchance allocate UNICODE_STRING on the stack, save a pointer to it
and then reference that pointer in another function after returning from the
originating function?

How fast did you plug and unplug the mouse? Did you allow “settling time”,
or were you simply masturbating the thing in a frenzy?

There are lots of questions, all of which you need to ask and answer before
you start pointing fingers at XP, or any other OS for that matter.


The personal opinion of
Gary G. Little

wrote in message news:xxxxx@ntdev…
>I test the USB device(e.g.USB Mouse).I found when i plug and plug about
> 1000 times can result in BSOD.
>
> I found RtlInitUnicodeString access memory violation.How can i resolve
> this
> problem.Who can explain What reason result in BSOD?
>
> Following is BugCheck analysis.
>
> *****
>
>
> * 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: 8052e77f, The address that the exception occurred at
> Arg3: aa8c23f8, Trap Frame
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - “0x%08lx”
>
> FAULTING_IP:
> nt!RtlInitUnicodeString+1b
> 8052e77f f266af repne scasw
>
> TRAP_FRAME: aa8c23f8 – (.trap ffffffffaa8c23f8)
> ErrCode = 00000000
> eax=00000000 ebx=f9a0a720 ecx=ffffffee edx=aa8c24ac esi=00c6e7a8
> edi=0016b000
> eip=8052e77f esp=aa8c246c ebp=aa8c2d30 iopl=0 nv up ei pl zr na po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010246
> nt!RtlInitUnicodeString+0x1b:
> 8052e77f f266af repne scasw es:0016b000
> =???
> Resetting default scope
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x8E
>
> LAST_CONTROL_TRANSFER: from 8053c4f4 to 8052e77f
>
> STACK_TEXT:
> aa8c24bc 8053c4f4 00000000 00000000 00000000 nt!RtlInitUnicodeString+0x1b
> aa8c2d30 8054160c 00000528 00000000 00000000 nt!_flsbuf+0xa3
> aa8c2d30 7c92eb94 00000528 00000000 00000000 nt!KiFastCallEntry+0xfc
> 00c6e770 7c92df6a 7c80f26f 00000528 00000000 ntdll!KiFastSystemCallRet
> 00c6e774 7c80f26f 00000528 00000000 00000000
> ntdll!ZwQueryDirectoryFile+0xc
> 00c6e7f0 760b7362 000c3978 00c6e87c 00000000 kernel32!FindNextFileW+0xaa
> 00c6ead0 760b758f 000c4898 00031d00 00092fa8
> setupapi!InfCacheSearchDirectory+0x470
> 00c6eb04 760a72d9 000c4898 00031d00 00092fa8
> setupapi!InfCacheSearchPath+0x52
> 00c6eba4 76083e4e 00000000 00000005 76082349
> setupapi!EnumDrvInfsInDirPathList+0x262
> 00c6f3b4 7e1f01d9 000b64a0 00c6fcf4 00000002
> setupapi!SetupDiBuildDriverInfoList+0x9a7
> 00c6ff1c 7e1e9a76 00d412e0 7e1fa1dc 00c6ff64
> umpnpmgr!InstallDeviceServerSide+0x144
> 00c6ffb4 7c80b50b 00000000 7c9363a8 00c2feb8
> umpnpmgr!ThreadProc_DeviceInstall+0x449
> 00c6ffec 00000000 7e1e5dbf 00000000 00000000 kernel32!BaseThreadStart+0x37
>
>
> FOLLOWUP_IP:
> nt!_flsbuf+a3
> 8053c4f4 43 inc ebx
>
> SYMBOL_STACK_INDEX: 1
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: nt!_flsbuf+a3
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntkrpamp.exe
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 42250a1e
>
> STACK_COMMAND: .trap ffffffffaa8c23f8 ; kb
>
> FAILURE_BUCKET_ID: 0x8E_nt!_flsbuf+a3
>
> BUCKET_ID: 0x8E_nt!_flsbuf+a3
>
> Followup: MachineOwner
>
> =========================================================================================================
>
>
> Best Regards
> Ken Wang
>
>
>

Of course, now that we know he’s building malware, perhaps we shouldn’t
help him…

As someone earlier pointed out, he’s run off the end of the page (notice
EDI is on a page boundary and that is the invalid memory address.)
Obviously, he assumes that the string being passed in is in valid memory
and is null terminated; my guess (based upon the value in ECX) is that
it is not null terminated, although I believe the passed in buffer is
valid to make it this far.

UNICODE strings are not required to be NULL terminated. If the string
is not null terminated and NOT up against the page boundary, it might
not blow up, but it might not work right, either.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Thursday, November 03, 2005 11:04 AM
To: ntdev redirect
Subject: Re:[ntdev] This is WinXP Bug?

And are you still hooking ZwQueryDirectoryFile? If so, I would say your
hook
is at fault.

Have you ran performance monitor and taken a look for memory leaks?
RtlInitUnicodeString requires two buffers; one to contain the
UNICODE_STRING
structure and one to contain the actual string. Are both of those being
released?

What is your IRQL? The C0000005 says access denied and that could be
caused
by being at DISPATCH_LEVEL and accessing paged memory.

As asked in another thread, and which I never saw your answer, is
SourceString a NULL terminated string?

Did you perchance allocate UNICODE_STRING on the stack, save a pointer
to it
and then reference that pointer in another function after returning from
the
originating function?

How fast did you plug and unplug the mouse? Did you allow “settling
time”,
or were you simply masturbating the thing in a frenzy?

There are lots of questions, all of which you need to ask and answer
before
you start pointing fingers at XP, or any other OS for that matter.


The personal opinion of
Gary G. Little

wrote in message news:xxxxx@ntdev…
>I test the USB device(e.g.USB Mouse).I found when i plug and plug about
> 1000 times can result in BSOD.
>
> I found RtlInitUnicodeString access memory violation.How can i resolve

> this
> problem.Who can explain What reason result in BSOD?
>
> Following is BugCheck analysis.
>
>
*****************************************************************

> *
> *
> * 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: 8052e77f, The address that the exception occurred at
> Arg3: aa8c23f8, Trap Frame
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - “0x%08lx”
>
> FAULTING_IP:
> nt!RtlInitUnicodeString+1b
> 8052e77f f266af repne scasw
>
> TRAP_FRAME: aa8c23f8 – (.trap ffffffffaa8c23f8)
> ErrCode = 00000000
> eax=00000000 ebx=f9a0a720 ecx=ffffffee edx=aa8c24ac esi=00c6e7a8
> edi=0016b000
> eip=8052e77f esp=aa8c246c ebp=aa8c2d30 iopl=0 nv up ei pl zr
na po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010246
> nt!RtlInitUnicodeString+0x1b:
> 8052e77f f266af repne scasw
es:0016b000
> =???
> Resetting default scope
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x8E
>
> LAST_CONTROL_TRANSFER: from 8053c4f4 to 8052e77f
>
> STACK_TEXT:
> aa8c24bc 8053c4f4 00000000 00000000 00000000
nt!RtlInitUnicodeString+0x1b
> aa8c2d30 8054160c 00000528 00000000 00000000 nt!_flsbuf+0xa3
> aa8c2d30 7c92eb94 00000528 00000000 00000000 nt!KiFastCallEntry+0xfc
> 00c6e770 7c92df6a 7c80f26f 00000528 00000000 ntdll!KiFastSystemCallRet
> 00c6e774 7c80f26f 00000528 00000000 00000000
> ntdll!ZwQueryDirectoryFile+0xc
> 00c6e7f0 760b7362 000c3978 00c6e87c 00000000
kernel32!FindNextFileW+0xaa
> 00c6ead0 760b758f 000c4898 00031d00 00092fa8
> setupapi!InfCacheSearchDirectory+0x470
> 00c6eb04 760a72d9 000c4898 00031d00 00092fa8
> setupapi!InfCacheSearchPath+0x52
> 00c6eba4 76083e4e 00000000 00000005 76082349
> setupapi!EnumDrvInfsInDirPathList+0x262
> 00c6f3b4 7e1f01d9 000b64a0 00c6fcf4 00000002
> setupapi!SetupDiBuildDriverInfoList+0x9a7
> 00c6ff1c 7e1e9a76 00d412e0 7e1fa1dc 00c6ff64
> umpnpmgr!InstallDeviceServerSide+0x144
> 00c6ffb4 7c80b50b 00000000 7c9363a8 00c2feb8
> umpnpmgr!ThreadProc_DeviceInstall+0x449
> 00c6ffec 00000000 7e1e5dbf 00000000 00000000
kernel32!BaseThreadStart+0x37
>
>
> FOLLOWUP_IP:
> nt!_flsbuf+a3
> 8053c4f4 43 inc ebx
>
> SYMBOL_STACK_INDEX: 1
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: nt!_flsbuf+a3
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntkrpamp.exe
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 42250a1e
>
> STACK_COMMAND: .trap ffffffffaa8c23f8 ; kb
>
> FAILURE_BUCKET_ID: 0x8E_nt!_flsbuf+a3
>
> BUCKET_ID: 0x8E_nt!_flsbuf+a3
>
> Followup: MachineOwner
>
>
========================================================================
=================================
>
>
> Best Regards
> Ken Wang
>
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com