FltGetVolumeFromName cause blue screen

OSR_Community_User · January 18, 2011, 2:05am

I’m developing a filter, i want to convert volume name, such as c:\a -> \Device\HarddiskVlume1\a, so i called function FltGetVolumeFromName, but in some WinXP computer, when reset it often cause blue screen, do everyone know what happen?

OSR_Community_User · January 18, 2011, 2:36am

åœ¨ 2011-01-18äºŒçš„ 02:04 -0500ï¼Œxxxxx@foxmail.comå†™é“ï¼š

I’m developing a filter, i want to convert volume name, such as c:\a -> \Device\HarddiskVlume1\a, so i called function FltGetVolumeFromName, but in some WinXP computer, when reset it often cause blue screen, do everyone know what happen?

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
I have no problem when use FltGetVolumnFromName.Maybe you have some
problem in UNICODE_STRING??Good Luck!

rod_widdowson · January 18, 2011, 3:56am

You’ll need to give us more than that.

What does the crash look like (you are looking at this with a debugger?
If not put one on)?
What is special about this machine?
Where are you calling this function (DriverEntry? PreCreate? Attach?
PostClose? Where?)

R

What is special about this co

åœ¨ 2011-01-18äºŒçš„ 02:04 -0500ï¼Œxxxxx@foxmail.comå†™é“ï¼š

I’m developing a filter, i want to convert volume name, such as c:\a ->
\Device\HarddiskVlume1\a, so i called function FltGetVolumeFromName, but
in some WinXP computer, when reset it often cause blue screen, do everyone
know what happen?

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

Gary_Little-3 · January 18, 2011, 7:04am

What have you done to debug the issue?Have you stepped into the code using WinDbg? What does !analyze -v provide?

Gary G. Little

----- Original Message -----
From: xxxxx@foxmail.com
To: “Windows File Systems Devs Interest List”
Sent: Tuesday, January 18, 2011 1:04:39 AM
Subject: [ntfsd] FltGetVolumeFromName cause blue screen

I’m developing a filter, i want to convert volume name, such as c:\a -> \Device\HarddiskVlume1\a, so i called function FltGetVolumeFromName, but in some WinXP computer, when reset it often cause blue screen, do everyone know what happen?

—
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

OSR_Community_User · January 18, 2011, 10:10pm

This is the dump information:
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [F:\share\FDS\BlueScreen\Mini011411-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*DownstreamStore*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_rtm.040803-2158
Machine Name:
Kernel base = 0x804d8000 PsLoadedModuleList = 0x8055d700
Debug session time: Fri Jan 14 10:58:12.531 2011 (GMT+8)
System Uptime: 0 days 0:00:24.234
Loading Kernel Symbols
…
…
Loading User Symbols
Loading unloaded module list
…
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000007F, {8, ba330d70, 0, 0}

*** WARNING: Unable to verify timestamp for FDS.sys
*** ERROR: Module load completed but symbols could not be loaded for FDS.sys
Probably caused by : FDS.sys ( FDS+329d )

Followup: MachineOwner

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

UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f)
This means a trap occurred in kernel mode, and it’s a trap of a kind
that the kernel isn’t allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: ba330d70
Arg3: 00000000
Arg4: 00000000

Debugging Details:

BUGCHECK_STR: 0x7f_8

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: System

LAST_CONTROL_TRANSFER: from b9d7eac8 to 8053bb8c

STACK_TEXT:
ba51102c b9d7eac8 e1a5c1a8 00000003 00000000 nt!_SEH_prolog+0x1c
ba51106c b9d7ebbb e1a5c168 00000003 00000000 Ntfs!NtfsLookupNtfsMcbEntry+0x9b
ba511178 b9d9f802 ba5117f0 e1a5c0d0 00000003 Ntfs!NtfsLookupAllocation+0x5b
ba5111bc b9d9ef5e ba5117f0 e1a5c0d0 00000003 Ntfs!LookupLcns+0x3a
ba51132c b9da87b5 ba5117f0 e1a5c0d0 89ed0510 Ntfs!NtfsWriteLog+0x454
ba5114c4 b9da88c9 ba5117f0 e1a5c0d0 e1d98820 Ntfs!NtfsUpdateFileNameInIndex+0x128
ba5115c0 b9da92b9 ba5117f0 e1d98570 e1d987d0 Ntfs!NtfsUpdateDuplicateInfo+0x2ab
ba5117d4 b9da3d83 ba5117f0 89c06de0 8a91fc80 Ntfs!NtfsCommonCleanup+0x2141
ba51194c 804efeb1 89f69770 89c06de0 8a94d328 Ntfs!NtfsFsdCleanup+0xcf
ba51195c b9e26bbf 89b90ee8 ba5119a8 ba511990 nt!IopfCallDriver+0x31
ba51196c 804efeb1 8a91fbc8 89c06de0 89c06fdc sr!SrCleanup+0xb3
ba51197c b9e37b2f 89c12c18 89c06de0 00000000 nt!IopfCallDriver+0x31
ba511990 b9e37ffb ba5119a8 89b90ee8 8a999250 fltMgr!FltpPassThrough+0xf9
ba5119c0 804efeb1 89c35ee8 89c06de0 89c06de0 fltMgr!FltpDispatch+0xf3
ba5119d0 80583617 89b90ed0 8a9a0900 00000001 nt!IopfCallDriver+0x31
ba511a00 805bc3a9 8a96e830 89c35ee8 00000080 nt!IopCloseFile+0x26b
ba511a30 805bbcfb 8a96e830 01b90ed0 8a9a0900 nt!ObpDecrementHandleCount+0x11b
ba511a58 805bbd99 e1001e10 89b90ee8 00000c8c nt!ObpCloseHandleTableEntry+0x14d
ba511aa0 805bbed1 00000c8c 00000000 00000000 nt!ObpCloseHandle+0x87
ba511ab4 8054160c 80000c8c ba511b78 805002a5 nt!NtClose+0x1d
ba511ab4 805002a5 80000c8c ba511b78 805002a5 nt!KiFastCallEntry+0xfc
ba511b30 9f20029d 80000c8c 00000000 0000001d nt!ZwClose+0x11
WARNING: Stack unwind information not available. Following frames may be wrong.
ba511b78 9f200451 ba513254 00000000 65897c88 FDS+0x329d
ba5127e4 9f1ff09e ba513254 00000001 00000000 FDS+0x3451
ba513c84 8058106a 89a6c690 89d6b000 00000000 FDS+0x209e
ba513d54 80581179 00000cec 00000001 00000000 nt!IopLoadDriver+0x66c
ba513d7c 80538757 00000cec 00000000 8a96b020 nt!IopLoadUnloadDriver+0x45
ba513dac 805cf794 a78a6cf4 00000000 00000000 nt!ExpWorkerThread+0xef
ba513ddc 805460ce 80538668 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
FDS+329d
9f20029d ?? ???

SYMBOL_STACK_INDEX: 16

SYMBOL_NAME: FDS+329d

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: FDS

IMAGE_NAME: FDS.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d2d4dcb

FAILURE_BUCKET_ID: 0x7f_8_FDS+329d

BUCKET_ID: 0x7f_8_FDS+329d

Followup: MachineOwner

I call the function in DriverEntry, the machine crash when it is starting, just before completely entry the system. But it work well when I setup before reset.

Scott_Noone_OSR · January 19, 2011, 9:37am

Usually 7F/8 is a stack overflow and it looks to me like it’s possible that
you ran out of kernel stack. Your functions also appear to be using a lot of
kernel stack (over 8K??), which would be a problem.

Does your code prefast clean? I’d imagine not…

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

Hope to see you at the next OSR kernel debugging class February 14th in
Columbia, MD!

wrote in message news:xxxxx@ntfsd…

This is the dump information:
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [F:\share\FDS\BlueScreen\Mini011411-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is:
SRV*DownstreamStore*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86
compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_rtm.040803-2158
Machine Name:
Kernel base = 0x804d8000 PsLoadedModuleList = 0x8055d700
Debug session time: Fri Jan 14 10:58:12.531 2011 (GMT+8)
System Uptime: 0 days 0:00:24.234
Loading Kernel Symbols
…
…
Loading User Symbols
Loading unloaded module list
…
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000007F, {8, ba330d70, 0, 0}

*** WARNING: Unable to verify timestamp for FDS.sys
*** ERROR: Module load completed but symbols could not be loaded for FDS.sys
Probably caused by : FDS.sys ( FDS+329d )

Followup: MachineOwner

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

UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f)
This means a trap occurred in kernel mode, and it’s a trap of a kind
that the kernel isn’t allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: ba330d70
Arg3: 00000000
Arg4: 00000000

Debugging Details:

BUGCHECK_STR: 0x7f_8

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: System

LAST_CONTROL_TRANSFER: from b9d7eac8 to 8053bb8c

STACK_TEXT:
ba51102c b9d7eac8 e1a5c1a8 00000003 00000000 nt!_SEH_prolog+0x1c
ba51106c b9d7ebbb e1a5c168 00000003 00000000
Ntfs!NtfsLookupNtfsMcbEntry+0x9b
ba511178 b9d9f802 ba5117f0 e1a5c0d0 00000003 Ntfs!NtfsLookupAllocation+0x5b
ba5111bc b9d9ef5e ba5117f0 e1a5c0d0 00000003 Ntfs!LookupLcns+0x3a
ba51132c b9da87b5 ba5117f0 e1a5c0d0 89ed0510 Ntfs!NtfsWriteLog+0x454
ba5114c4 b9da88c9 ba5117f0 e1a5c0d0 e1d98820
Ntfs!NtfsUpdateFileNameInIndex+0x128
ba5115c0 b9da92b9 ba5117f0 e1d98570 e1d987d0
Ntfs!NtfsUpdateDuplicateInfo+0x2ab
ba5117d4 b9da3d83 ba5117f0 89c06de0 8a91fc80 Ntfs!NtfsCommonCleanup+0x2141
ba51194c 804efeb1 89f69770 89c06de0 8a94d328 Ntfs!NtfsFsdCleanup+0xcf
ba51195c b9e26bbf 89b90ee8 ba5119a8 ba511990 nt!IopfCallDriver+0x31
ba51196c 804efeb1 8a91fbc8 89c06de0 89c06fdc sr!SrCleanup+0xb3
ba51197c b9e37b2f 89c12c18 89c06de0 00000000 nt!IopfCallDriver+0x31
ba511990 b9e37ffb ba5119a8 89b90ee8 8a999250 fltMgr!FltpPassThrough+0xf9
ba5119c0 804efeb1 89c35ee8 89c06de0 89c06de0 fltMgr!FltpDispatch+0xf3
ba5119d0 80583617 89b90ed0 8a9a0900 00000001 nt!IopfCallDriver+0x31
ba511a00 805bc3a9 8a96e830 89c35ee8 00000080 nt!IopCloseFile+0x26b
ba511a30 805bbcfb 8a96e830 01b90ed0 8a9a0900
nt!ObpDecrementHandleCount+0x11b
ba511a58 805bbd99 e1001e10 89b90ee8 00000c8c
nt!ObpCloseHandleTableEntry+0x14d
ba511aa0 805bbed1 00000c8c 00000000 00000000 nt!ObpCloseHandle+0x87
ba511ab4 8054160c 80000c8c ba511b78 805002a5 nt!NtClose+0x1d
ba511ab4 805002a5 80000c8c ba511b78 805002a5 nt!KiFastCallEntry+0xfc
ba511b30 9f20029d 80000c8c 00000000 0000001d nt!ZwClose+0x11
WARNING: Stack unwind information not available. Following frames may be
wrong.
ba511b78 9f200451 ba513254 00000000 65897c88 FDS+0x329d
ba5127e4 9f1ff09e ba513254 00000001 00000000 FDS+0x3451
ba513c84 8058106a 89a6c690 89d6b000 00000000 FDS+0x209e
ba513d54 80581179 00000cec 00000001 00000000 nt!IopLoadDriver+0x66c
ba513d7c 80538757 00000cec 00000000 8a96b020 nt!IopLoadUnloadDriver+0x45
ba513dac 805cf794 a78a6cf4 00000000 00000000 nt!ExpWorkerThread+0xef
ba513ddc 805460ce 80538668 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
FDS+329d
9f20029d ?? ???

SYMBOL_STACK_INDEX: 16

SYMBOL_NAME: FDS+329d

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: FDS

IMAGE_NAME: FDS.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d2d4dcb

FAILURE_BUCKET_ID: 0x7f_8_FDS+329d

BUCKET_ID: 0x7f_8_FDS+329d

Followup: MachineOwner

I call the function in DriverEntry, the machine crash when it is starting,
just before completely entry the system. But it work well when I setup
before reset.

priynk · January 25, 2011, 5:19am

Do you have un-named volumes?

Regards,
Priynk

On Wed, Jan 19, 2011 at 8:07 PM, Scott Noone wrote:

> Usually 7F/8 is a stack overflow and it looks to me like it’s possible that
> you ran out of kernel stack. Your functions also appear to be using a lot of
> kernel stack (over 8K??), which would be a problem.
>
> Does your code prefast clean? I’d imagine not…
>
> -scott
>
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> Hope to see you at the next OSR kernel debugging class February 14th in
> Columbia, MD!
>
> wrote in message news:xxxxx@ntfsd…
>
>
> This is the dump information:
> Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
> Copyright (c) Microsoft Corporation. All rights reserved.
>
>
> Loading Dump File [F:\share\FDS\BlueScreen\Mini011411-01.dmp]
> Mini Kernel Dump File: Only registers and stack trace are available
>
> Symbol search path is: SRVDownstreamStore
> http://msdl.microsoft.com/download/symbols
> Executable search path is:
> Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86
> compatible
> Product: WinNt, suite: TerminalServer SingleUserTS
> Built by: 2600.xpsp_sp2_rtm.040803-2158
> Machine Name:
> Kernel base = 0x804d8000 PsLoadedModuleList = 0x8055d700
> Debug session time: Fri Jan 14 10:58:12.531 2011 (GMT+8)
> System Uptime: 0 days 0:00:24.234
> Loading Kernel Symbols
> …
> …
> Loading User Symbols
> Loading unloaded module list
> …
>
> ***
> *
> * Bugcheck Analysis
> *
>
>
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck 1000007F, {8, ba330d70, 0, 0}
>
> WARNING: Unable to verify timestamp for FDS.sys
> ERROR: Module load completed but symbols could not be loaded for
> FDS.sys
> Probably caused by : FDS.sys ( FDS+329d )
>
> Followup: MachineOwner
> ---------
>
> 1: kd> !analyze -v
>
> ***
> *
> * Bugcheck Analysis
> *
>
>
>
> UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f)
> This means a trap occurred in kernel mode, and it’s a trap of a kind
> that the kernel isn’t allowed to have/catch (bound trap) or that
> is always instant death (double fault). The first number in the
> bugcheck params is the number of the trap (8 = double fault, etc)
> Consult an Intel x86 family manual to learn more about what these
> traps are. Here is a portion of those codes:
> If kv shows a taskGate
> use .tss on the part before the colon, then kv.
> Else if kv shows a trapframe
> use .trap on that value
> Else
> .trap on the appropriate frame will show where the trap was taken
> (on x86, this will be the ebp that goes with the procedure KiTrap)
> Endif
> kb will then show the corrected stack.
> Arguments:
> Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
> Arg2: ba330d70
> Arg3: 00000000
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
>
> BUGCHECK_STR: 0x7f_8
>
> CUSTOMER_CRASH_COUNT: 1
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> PROCESS_NAME: System
>
> LAST_CONTROL_TRANSFER: from b9d7eac8 to 8053bb8c
>
> STACK_TEXT:
> ba51102c b9d7eac8 e1a5c1a8 00000003 00000000 nt!_SEH_prolog+0x1c
> ba51106c b9d7ebbb e1a5c168 00000003 00000000
> Ntfs!NtfsLookupNtfsMcbEntry+0x9b
> ba511178 b9d9f802 ba5117f0 e1a5c0d0 00000003 Ntfs!NtfsLookupAllocation+0x5b
> ba5111bc b9d9ef5e ba5117f0 e1a5c0d0 00000003 Ntfs!LookupLcns+0x3a
> ba51132c b9da87b5 ba5117f0 e1a5c0d0 89ed0510 Ntfs!NtfsWriteLog+0x454
> ba5114c4 b9da88c9 ba5117f0 e1a5c0d0 e1d98820
> Ntfs!NtfsUpdateFileNameInIndex+0x128
> ba5115c0 b9da92b9 ba5117f0 e1d98570 e1d987d0
> Ntfs!NtfsUpdateDuplicateInfo+0x2ab
> ba5117d4 b9da3d83 ba5117f0 89c06de0 8a91fc80 Ntfs!NtfsCommonCleanup+0x2141
> ba51194c 804efeb1 89f69770 89c06de0 8a94d328 Ntfs!NtfsFsdCleanup+0xcf
> ba51195c b9e26bbf 89b90ee8 ba5119a8 ba511990 nt!IopfCallDriver+0x31
> ba51196c 804efeb1 8a91fbc8 89c06de0 89c06fdc sr!SrCleanup+0xb3
> ba51197c b9e37b2f 89c12c18 89c06de0 00000000 nt!IopfCallDriver+0x31
> ba511990 b9e37ffb ba5119a8 89b90ee8 8a999250 fltMgr!FltpPassThrough+0xf9
> ba5119c0 804efeb1 89c35ee8 89c06de0 89c06de0 fltMgr!FltpDispatch+0xf3
> ba5119d0 80583617 89b90ed0 8a9a0900 00000001 nt!IopfCallDriver+0x31
> ba511a00 805bc3a9 8a96e830 89c35ee8 00000080 nt!IopCloseFile+0x26b
> ba511a30 805bbcfb 8a96e830 01b90ed0 8a9a0900
> nt!ObpDecrementHandleCount+0x11b
> ba511a58 805bbd99 e1001e10 89b90ee8 00000c8c
> nt!ObpCloseHandleTableEntry+0x14d
> ba511aa0 805bbed1 00000c8c 00000000 00000000 nt!ObpCloseHandle+0x87
> ba511ab4 8054160c 80000c8c ba511b78 805002a5 nt!NtClose+0x1d
> ba511ab4 805002a5 80000c8c ba511b78 805002a5 nt!KiFastCallEntry+0xfc
> ba511b30 9f20029d 80000c8c 00000000 0000001d nt!ZwClose+0x11
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> ba511b78 9f200451 ba513254 00000000 65897c88 FDS+0x329d
> ba5127e4 9f1ff09e ba513254 00000001 00000000 FDS+0x3451
> ba513c84 8058106a 89a6c690 89d6b000 00000000 FDS+0x209e
> ba513d54 80581179 00000cec 00000001 00000000 nt!IopLoadDriver+0x66c
> ba513d7c 80538757 00000cec 00000000 8a96b020 nt!IopLoadUnloadDriver+0x45
> ba513dac 805cf794 a78a6cf4 00000000 00000000 nt!ExpWorkerThread+0xef
> ba513ddc 805460ce 80538668 00000001 00000000 nt!PspSystemThreadStartup+0x34
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> FDS+329d
> 9f20029d ?? ???
>
> SYMBOL_STACK_INDEX: 16
>
> SYMBOL_NAME: FDS+329d
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: FDS
>
> IMAGE_NAME: FDS.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 4d2d4dcb
>
> FAILURE_BUCKET_ID: 0x7f_8_FDS+329d
>
> BUCKET_ID: 0x7f_8_FDS+329d
>
> Followup: MachineOwner
> ---------
> I call the function in DriverEntry, the machine crash when it is starting,
> just before completely entry the system. But it work well when I setup
> before reset.
>
>
> —
> 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
>