KiPageFault into BSOD when stepping over

Andrii wrote:

Hello, Alex.

kd> bp MyVolFlt!MyVolFltEvtDeviceAdd
kd> g
Break instruction exception - code 80000003 (first chance)
MyVolFlt!MyVolFltEvtDeviceAdd:
fffff800`011be0e0 cc int 3
1: kd> g
KDTARGET: Refreshing KD connection

*** Fatal System Error: 0x00000050

(0xFFFFE00020464C10,0x0000000000000000,0xFFFFF800002692E3,0x00000000000

So the same :frowning: And its not about only this code. I get similar
bugchecks while debugging other drivers (this one is just a skeleton
project with nearly no real work performed).

If I set bp right after WdfFdoInitQueryProperty call - it runs like a
charm.

Probably I must mention my environment:

  1. Host - Windows 8.1 Enterprise x64 with Hyper-V
  2. Target - Windows 8.1 Enterprise x64 under Hyper-V
  3. WinDbg 6.3.9600.16384 (WDK 8.1)
  4. VM got COM1 configured as a pipe for KD
  5. bootdebug is enabled
  6. Target is FRE build

My only guess was Dynamic Memory in VM configuration. So I disabled
it.
Still no luck.

Ha! Curiouser and curiouser!
Actually, I think the only person on this list who can shed some light
on it is Doron Holan - he, after all is the KMDF man at Microsoft.
BTW, does this happen when debugging target is physical Windows 8.1
machine and not a VM?

Best regards,
Alex Krol

Dr. Newcomer wrote:

No. The code is wrong

The code in question is

__checkReturn
__drv_maxIRQL(PASSIVE_LEVEL)
NTSTATUS
FORCEINLINE
WdfFdoInitQueryProperty(
__in
PWDFDEVICE_INIT DeviceInit,
__in
DEVICE_REGISTRY_PROPERTY DeviceProperty,
__in
ULONG BufferLength,
__out_bcount_full_opt(BufferLength)
PVOID PropertyBuffer,
__out
PULONG ResultLength
)
{
return ((PFN_WDFFDOINITQUERYPROPERTY)
WdfFunctions[WdfFdoInitQueryPropertyTableIndex])(WdfDriverGlobals,
DeviceInit, DeviceProperty, BufferLength, PropertyBuffer, ResultLength);
}

(Well, it is copypasted from old KMDF 1.9, but this inlined function was
not changed in later ones).
You are seeing in debugger output just last lines starting from
PULONG ResultLength

  • and missing the closing ).

Best regards,
Alex Krol

Alex, I don’t have physical machine available for debugging here :frowning:

And a small update. After first call to WdfFdoInitQueryProperty references rdx=DeviceInit:
fffff800`003702e3 488b1a mov rbx,qword ptr [rdx]

consequent step overs don’t trigger bug checks. WDFDEVICE_INIT structure is allocated by framework and must be valid at that point.

Second run with step into WdfFdoInitQueryProperty:
1: kd> !pool ffffe000017d8e20 <- rdx = DeviceInit
Pool page ffffe000017d8e20 region is Nonpaged pool

*ffffe000017d8e10 size: 1f0 previous size: 1c0 (Allocated) *FxDr
Pooltag FxDr : KMDF driver globals/generic pool allocation tag. Fallback tag in case driver tag is unusable., Binary : wdf01000.sys

What does ‘!pte ffffe000`20464c10’ say (run on dump from your first post)?

Kris

On Tue, Jan 14, 2014 at 12:49 PM, wrote:
> Second run with step into WdfFdoInitQueryProperty:
> 1: kd> !pool ffffe000017d8e20 <- rdx = DeviceInit
> Pool page ffffe000017d8e20 region is Nonpaged pool
> …
> *ffffe000017d8e10 size: 1f0 previous size: 1c0 (Allocated) *FxDr
> Pooltag FxDr : KMDF driver globals/generic pool allocation tag. Fallback tag in case driver tag is unusable., Binary : wdf01000.sys
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other 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


Kris

I haven’t done anything in KMDF for couple of years now so it might be
completely unrelated but did you check what’s going on the other CPUs?
I saw race conditions being more “visible” when debug stepping.

Kris

On Tue, Jan 14, 2014 at 1:21 PM, Krzysztof Uchronski wrote:
> What does ‘!pte ffffe000`20464c10’ say (run on dump from your first post)?
>
> Kris
>
> On Tue, Jan 14, 2014 at 12:49 PM, wrote:
>> Second run with step into WdfFdoInitQueryProperty:
>> 1: kd> !pool ffffe000017d8e20 <- rdx = DeviceInit
>> Pool page ffffe000017d8e20 region is Nonpaged pool
>> …
>> *ffffe000017d8e10 size: 1f0 previous size: 1c0 (Allocated) *FxDr
>> Pooltag FxDr : KMDF driver globals/generic pool allocation tag. Fallback tag in case driver tag is unusable., Binary : wdf01000.sys
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other 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
>
>
>
> –
> Kris


Kris

Krzysztof, I was digging this right before you wrote :slight_smile:

Before unsuccessful call to WdfFdoInitQueryProperty (bp before call is made)
1: kd> !pte poi(DeviceInit)
VA ffffe00020464c10
PXE at FFFFF6FB7DBEDE00 PPE at FFFFF6FB7DBC0000 PDE at FFFFF6FB78000810 PTE at FFFFF6F000102320
contains 0000000000381863 contains 0000000000382863 contains 0000000000000000
pfn 381 —DA–KWEV pfn 382 —DA–KWEV not valid

After successful call to WdfFdoInitQueryProperty (bp after the call is made):

1: kd> !pte poi(DeviceInit)
VA ffffd00020464c10
PXE at FFFFF6FB7DBEDD00 PPE at FFFFF6FB7DBA0000 PDE at FFFFF6FB74000810 PTE at FFFFF6E800102320
contains 00000000002A4863 contains 00000000002A3863 contains 0000000000541863 contains 8000000002820963
pfn 2a4 —DA–KWEV pfn 2a3 —DA–KWEV pfn 541 —DA–KWEV pfn 2820 -G-DA–KW-V

Does this mean Windows fixes kernel PTEs on the fly? OK, but why does it bugcheck at that point?

PS: Other cores are idle.

  1. Do you ever map memory as non-cached, by any chance?

  2. List the breakpoints: bl

Does it show any stray breakpoints you forgot about?

Iirc, DeviceInit is stack based on the call to AddDevice so I am not sure how !pte handles stack addresses. As for the break, this has nothing to do with kmdf, rather the debugger interacting with the os.
d
Bent from my phone


From: xxxxx@gmail.commailto:xxxxx
Sent: ?1/?14/?2014 5:44 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] KiPageFault into BSOD when stepping over

Krzysztof, I was digging this right before you wrote :slight_smile:

Before unsuccessful call to WdfFdoInitQueryProperty (bp before call is made)
1: kd> !pte poi(DeviceInit)
VA ffffe00020464c10
PXE at FFFFF6FB7DBEDE00 PPE at FFFFF6FB7DBC0000 PDE at FFFFF6FB78000810 PTE at FFFFF6F000102320
contains 0000000000381863 contains 0000000000382863 contains 0000000000000000
pfn 381 —DA–KWEV pfn 382 —DA–KWEV not valid

After successful call to WdfFdoInitQueryProperty (bp after the call is made):

1: kd> !pte poi(DeviceInit)
VA ffffd00020464c10
PXE at FFFFF6FB7DBEDD00 PPE at FFFFF6FB7DBA0000 PDE at FFFFF6FB74000810 PTE at FFFFF6E800102320
contains 00000000002A4863 contains 00000000002A3863 contains 0000000000541863 contains 8000000002820963
pfn 2a4 —DA–KWEV pfn 2a3 —DA–KWEV pfn 541 —DA–KWEV pfn 2820 -G-DA–KW-V

Does this mean Windows fixes kernel PTEs on the fly? OK, but why does it bugcheck at that point?


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other 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</mailto:xxxxx></mailto:xxxxx>

I’m sure it’s not KMDF’s fault since I get similar behavior without KMDF. As I said it looks like kd side effect.
The biggest issue is that debugging experience suffers cause of restarts I’m forced into by bug checks. There were no problems without the debugger.

Since this is breaking in at DeviceAdd() of a volume filter, is this the boot disk? Are you halting the OS during boot, so that when you start stepping you hit page fault timeouts?

Just a common occurrence that should be checked first …

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, January 14, 2014 7:21 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KiPageFault into BSOD when stepping over

I’m sure it’s not KMDF’s fault since I get similar behavior without KMDF. As I said it looks like kd side effect.
The biggest issue is that debugging experience suffers cause of restarts I’m forced into by bug checks. There were no problems without the debugger.


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other 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’ve seen this problem before when doing boot debugging. I suspect that a
breakpoint has been set in the boot debugger, but that information has not
been properly handed off to the normal kernel debugger.

As we know, a software breakpoint is set by replacing a byte in the
instruction stream with a 0xCC (“int 3”). It’s the debugger’s job to handle
this breakpoint and swap the original byte back in before you hit “go”. Note
from the debugger output the O/S thinks that the first instruction in your
code is “int 3”!

kd> bp MyVolFlt!MyVolFltEvtDeviceAdd
kd> g
Break instruction exception - code 80000003 (first chance)
MyVolFlt!MyVolFltEvtDeviceAdd:
fffff800`011be0e0 cc int 3

This is serious bad business, if the debugger was working properly this
should be abstracted from you and you would see the first compiler generated
instruction. If the debugger does not put the original byte back, then the
instruction stream is hosed and you’ll get a bugcheck 50.

I have yet to try to nail this down more, but I’ve definitely seen it
frequently in VMWare environments. Options:

  1. Stop enabling boot debugging if you don’t need it

  2. Add a temporary __debugbreak() call in your code (don’t forget to remove
    it!)

  3. Do your own breakpoints by swapping the byte yourself (“db” to find out
    what it is, “eb” to modify it). This sounds stupid and annoying, which it
    is, but it worked for me once in a pinch.

-scott
OSR

“Speer, Kenny” wrote in message news:xxxxx@ntdev…

Since this is breaking in at DeviceAdd() of a volume filter, is this the
boot disk? Are you halting the OS during boot, so that when you start
stepping you hit page fault timeouts?

Just a common occurrence that should be checked first …

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, January 14, 2014 7:21 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KiPageFault into BSOD when stepping over

I’m sure it’s not KMDF’s fault since I get similar behavior without KMDF. As
I said it looks like kd side effect.
The biggest issue is that debugging experience suffers cause of restarts I’m
forced into by bug checks. There were no problems without the debugger.


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other 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

So I guess hardware breakpoints would workaround the problem as well.

Kris

On Tuesday, 14 January 2014, Scott Noone wrote:

I’ve seen this problem before when doing boot debugging. I suspect that a
breakpoint has been set in the boot debugger, but that information has not
been properly handed off to the normal kernel debugger.

As we know, a software breakpoint is set by replacing a byte in the
instruction stream with a 0xCC (“int 3”). It’s the debugger’s job to handle
this breakpoint and swap the original byte back in before you hit “go”.
Note from the debugger output the O/S thinks that the first instruction in
your code is “int 3”!

kd> bp MyVolFlt!MyVolFltEvtDeviceAdd
kd> g
Break instruction exception - code 80000003 (first chance)
MyVolFlt!MyVolFltEvtDeviceAdd:
fffff800`011be0e0 cc int 3

This is serious bad business, if the debugger was working properly this
should be abstracted from you and you would see the first compiler
generated instruction. If the debugger does not put the original byte back,
then the instruction stream is hosed and you’ll get a bugcheck 50.

I have yet to try to nail this down more, but I’ve definitely seen it
frequently in VMWare environments. Options:

  1. Stop enabling boot debugging if you don’t need it

  2. Add a temporary __debugbreak() call in your code (don’t forget to
    remove it!)

  3. Do your own breakpoints by swapping the byte yourself (“db” to find out
    what it is, “eb” to modify it). This sounds stupid and annoying, which it
    is, but it worked for me once in a pinch.

-scott
OSR

“Speer, Kenny” wrote in message news:xxxxx@ntdev…

Since this is breaking in at DeviceAdd() of a volume filter, is this the
boot disk? Are you halting the OS during boot, so that when you start
stepping you hit page fault timeouts?

Just a common occurrence that should be checked first …

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:
xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, January 14, 2014 7:21 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KiPageFault into BSOD when stepping over

I’m sure it’s not KMDF’s fault since I get similar behavior without KMDF.
As I said it looks like kd side effect.
The biggest issue is that debugging experience suffers cause of restarts
I’m forced into by bug checks. There were no problems without the debugger.


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other 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


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other 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


Kris

Scott, bp is set during normal debugging session. I use boot debugger only for .kdfiles to make WinDbg upload fresh sys file. int 3 works fine, don’t blame proven technique :).

I was sure this problem is well known. Should I change my configuration?

I would suggest allowing your system to boot, then set your breakpoint, and add another disk (either iscsi/fc* or if virtualized, a vmdk or vhdx) then your EvtDeviceAdd() routine will be called again.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, January 14, 2014 3:16 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KiPageFault into BSOD when stepping over

Scott, bp is set during normal debugging session. I use boot debugger only for .kdfiles to make WinDbg upload fresh sys file. int 3 works fine, don’t blame proven technique :).

I was sure this problem is well known. Should I change my configuration?


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other 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

Hardware breakpoints should indeed avoid the crash. OP: does setting .allow_bp_ba_convert 1 make the problem go away?

I’m not sure what exactly causes the issue, so I don’t know what to suggest in terms of changing your configuration. Every time I have hit it I’ve used one of the workarounds and made a note to isolate a repro and investigate in my copious free time :slight_smile:

-scott
OSR

Now I finally managed to figure out what was wrong. I would normally set my bp during initial break-in sequence:

Connected to Windows 8 9600 x64 target at (Thu Jan 16 00:54:33.435 2014 (UTC + 2:00)), ptr64 TRUE
Kernel Debugger connection established.
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred cache*C:\Development\Tools\Symbols
Deferred srv*http://msdl.microsoft.com/download/symbols
Symbol search path is: cache*C:\Development\Tools\Symbols;srv*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 9600 MP (1 procs) Free x64
Built by: 9600.16452.amd64fre.winblue_gdr.131030-1505
Machine Name:
Kernel base = 0xfffff8005547e000 PsLoadedModuleList = 0xfffff80055742990
System Uptime: 0 days 0:00:00.102
nt!DebugService2+0x5:
fffff800`555d28e5 cc int 3
kd> bp MyVolFltEvtDeviceAdd
kd> g

And here what happens after:

Unload module \SystemRoot\system32\mcupdate_GenuineIntel.dll at fffff8001b200000 Unload module \SystemRoot\System32\drivers\werkernel.sys at fffff80019ed5000

Unload module \SystemRoot\system32\DRIVERS\MyVolFlt.sys at fffff8001b9ed000 nt!DebugService2+0x5: fffff800555d28e5 cc int 3
kd> k

Child-SP RetAddr Call Site

00 fffff800573991a8 fffff80055544361 nt!DebugService2+0x5
01 fffff800573991b0 fffff800555442ff nt!DbgLoadImageSymbols+0x45
02 fffff80057399200 fffff80055b76fc4 nt!DbgLoadImageSymbolsUnicode+0x2b
03 fffff80057399240 fffff80055b7684b nt!MiReloadBootLoadedDrivers+0x300
04 fffff800573993c0 fffff80055b6c091 nt!MiInitializeDriverImages+0x163
05 fffff80057399470 fffff80055b67299 nt!MiInitSystem+0x3d9
06 fffff80057399500 fffff800557e84ea nt!InitBootProcessor+0x301
07 fffff80057399740 fffff800557de1a3 nt!KiInitializeKernel+0x5a2
08 fffff80057399ad0 0000000000000000 nt!KiSystemStartup+0x193

It is unloading boot time drivers! And reloading with different start addresses! So when I set my breakpoint at MyVolFltEvtDeviceAdd, WinDbg would insert int 3 instruction and during module relocation that instruction is copied as is. So my breakpoint actually hits, despite code relocation. But this is where the Windows and debugger fall apart - they don’t know about this breakpoint.

can you try setting a Bu myvolfiXXXX instead of bp myvolXXXX during
initial boot seuence and see if you can reproduce behaviour

bp is documented to track address while bu tracks symbols

sorry if iam way off as i havent got the trail of this thread and
havent visited the forum to lookup while answering

On 1/16/14, xxxxx@gmail.com wrote:
> Now I finally managed to figure out what was wrong. I would normally set my
> bp during initial break-in sequence:
>
> Connected to Windows 8 9600 x64 target at (Thu Jan 16 00:54:33.435 2014 (UTC
> + 2:00)), ptr64 TRUE
> Kernel Debugger connection established.
> Symbol Path validation summary*
> Response Time (ms) Location
> Deferred
> cacheC:\Development\Tools\Symbols
> Deferred
> srv
http://msdl.microsoft.com/download/symbols
> Symbol search path is:
> cacheC:\Development\Tools\Symbols;srvhttp://msdl.microsoft.com/download/symbols
> Executable search path is:
> Windows 8 Kernel Version 9600 MP (1 procs) Free x64
> Built by: 9600.16452.amd64fre.winblue_gdr.131030-1505
> Machine Name:
> Kernel base = 0xfffff8005547e000 PsLoadedModuleList = 0xfffff80055742990
> System Uptime: 0 days 0:00:00.102
> nt!DebugService2+0x5:
> fffff800555d28e5 cc int 3<br>&gt; kd&gt; bp MyVolFltEvtDeviceAdd<br>&gt; kd&gt; g<br>&gt;<br>&gt; And here what happens after:<br>&gt;<br>&gt; Unload module \SystemRoot\system32\mcupdate_GenuineIntel.dll at<br>&gt; fffff8001b200000
> Unload module \SystemRoot\System32\drivers\werkernel.sys at
> fffff80019ed5000<br>&gt; ...<br>&gt; Unload module \SystemRoot\system32\DRIVERS\MyVolFlt.sys at<br>&gt; fffff8001b9ed000
> nt!DebugService2+0x5:
> fffff800555d28e5 cc int 3<br>&gt; kd&gt; k<br>&gt; # Child-SP RetAddr Call Site<br>&gt; 00 fffff800573991a8 fffff80055544361 nt!DebugService2+0x5<br>&gt; 01 fffff800573991b0 fffff800555442ff nt!DbgLoadImageSymbols+0x45<br>&gt; 02 fffff80057399200 fffff80055b76fc4 nt!DbgLoadImageSymbolsUnicode+0x2b<br>&gt; 03 fffff80057399240 fffff80055b7684b nt!MiReloadBootLoadedDrivers+0x300<br>&gt; 04 fffff800573993c0 fffff80055b6c091 nt!MiInitializeDriverImages+0x163<br>&gt; 05 fffff80057399470 fffff80055b67299 nt!MiInitSystem+0x3d9<br>&gt; 06 fffff80057399500 fffff800557e84ea nt!InitBootProcessor+0x301<br>&gt; 07 fffff80057399740 fffff800557de1a3 nt!KiInitializeKernel+0x5a2<br>&gt; 08 fffff80057399ad0 00000000`00000000 nt!KiSystemStartup+0x193
>
> It is unloading boot time drivers! And reloading with different start
> addresses! So when I set my breakpoint at MyVolFltEvtDeviceAdd, WinDbg would
> insert int 3 instruction and during module relocation that instruction is
> copied as is. So my breakpoint actually hits, despite code relocation. But
> this is where the Windows and debugger fall apart - they don’t know about
> this breakpoint.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other 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
>

Excellent find, another mystery solved. Certainly seems like there’s some
missing coordination here between the KD module and the Mm module.

-scott
OSR

wrote in message news:xxxxx@ntdev…

Now I finally managed to figure out what was wrong. I would normally set my
bp during initial break-in sequence:

Connected to Windows 8 9600 x64 target at (Thu Jan 16 00:54:33.435 2014 (UTC

  • 2:00)), ptr64 TRUE
    Kernel Debugger connection established.
    ************* Symbol Path validation summary **************
    Response Time (ms) Location
    Deferred
    cache*C:\Development\Tools\Symbols
    Deferred
    srv*http://msdl.microsoft.com/download/symbols
    Symbol search path is:
    cache*C:\Development\Tools\Symbols;srv*http://msdl.microsoft.com/download/symbols
    Executable search path is:
    Windows 8 Kernel Version 9600 MP (1 procs) Free x64
    Built by: 9600.16452.amd64fre.winblue_gdr.131030-1505
    Machine Name:
    Kernel base = 0xfffff8005547e000 PsLoadedModuleList = 0xfffff80055742990
    System Uptime: 0 days 0:00:00.102
    nt!DebugService2+0x5:
    fffff800`555d28e5 cc int 3
    kd> bp MyVolFltEvtDeviceAdd
    kd> g

And here what happens after:

Unload module \SystemRoot\system32\mcupdate_GenuineIntel.dll at
fffff8001b200000 Unload module \SystemRoot\System32\drivers\werkernel.sys at fffff80019ed5000

Unload module \SystemRoot\system32\DRIVERS\MyVolFlt.sys at fffff8001b9ed000 nt!DebugService2+0x5: fffff800555d28e5 cc int 3
kd> k

Child-SP RetAddr Call Site

00 fffff800573991a8 fffff80055544361 nt!DebugService2+0x5
01 fffff800573991b0 fffff800555442ff nt!DbgLoadImageSymbols+0x45
02 fffff80057399200 fffff80055b76fc4 nt!DbgLoadImageSymbolsUnicode+0x2b
03 fffff80057399240 fffff80055b7684b nt!MiReloadBootLoadedDrivers+0x300
04 fffff800573993c0 fffff80055b6c091 nt!MiInitializeDriverImages+0x163
05 fffff80057399470 fffff80055b67299 nt!MiInitSystem+0x3d9
06 fffff80057399500 fffff800557e84ea nt!InitBootProcessor+0x301
07 fffff80057399740 fffff800557de1a3 nt!KiInitializeKernel+0x5a2
08 fffff80057399ad0 0000000000000000 nt!KiSystemStartup+0x193

It is unloading boot time drivers! And reloading with different start
addresses! So when I set my breakpoint at MyVolFltEvtDeviceAdd, WinDbg would
insert int 3 instruction and during module relocation that instruction is
copied as is. So my breakpoint actually hits, despite code relocation. But
this is where the Windows and debugger fall apart - they don’t know about
this breakpoint.