about xp x64

OSR_Community_User · November 20, 2009, 9:40am

on windows xp x64, dbgview hook nt!DbgPrint and there no bluescreen,but when i hook some api, get bluescreen!why??

OSR_Community_User · November 20, 2009, 9:47am

this is describe:

http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx

DebugView Capture
Under Windows 2000, XP, Server 2003 and Vista DebugView will capture:

Win32 OutputDebugString
Kernel-mode DbgPrint
All kernel-mode variants of DbgPrint implemented in Windows XP and Server 2003
DebugView also extracts kernel-mode debug output generated before a crash from Window’s 2000/XP crash dump files if DebugView was capturing at the time of the crash.

DebugView Capabilites
DebugView has a powerful array of features for controlling and managing debug output.

Features new to version 4.6:

Support for Windows Vista 32-bit and 64-bit
Features new to version 4.5:

Support for log-file rollover: To better support long-running captures, DebugView can now create a new log file each day, optionally clearing the display when doing so.
Features new to version 4.4:

Support for Windows Server 2003 64-bit Edition and Windows XP 64-bit Edition for x64:DebugView now captures kernel-mode debug output on 64-bit versions of Windows.
Clock-time toggle: you can now toggle between clock time and elapsed time modes.
Features new to version 4.3:

Tim_Roberts · November 20, 2009, 1:19pm

xxxxx@gmail.com wrote:

on windows xp x64, dbgview hook nt!DbgPrint and there no bluescreen,but when i hook some api, get bluescreen!why??

What makes you think they hook DbgPrint? The DbgPrint circular buffer
is exposed in a fully documented way, and can be read without any hooking.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Michal_Vodicka-2 · November 20, 2009, 6:52pm

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, November 20, 2009 7:19 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] about xp x64

What makes you think they hook DbgPrint? The DbgPrint circular buffer
is exposed in a fully documented way, and can be read without
any hooking.

Are you sure? It is OutputDebugString() which uses this circular buffer.
DebugView really hooked DbgPrint() in the past but it is long time ago
when I examined it (at 32-bit OS). At x64 I’d expect they do it properly
and install own interrupt handler for debug service (was int 2dh in the
past). It can be answer to OP’s question but I haven’t verified it.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

OSR_Community_User · November 20, 2009, 10:26pm

Thanks!

If there is only nt!DebugPrint hook,we get no bluescreen!
But when I add nt!NtCreateSection hook, we get bluescreen in a moment!

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

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or data have been corrupted. There are generally three causes for a corruption:

A driver has inadvertently or deliberately modified critical kernel code or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
A developer attempted to set a normal kernel breakpoint using a kernel debugger that was not attached when the system was booted. Normal breakpoints, “bp”, can only be set if the debugger is attached at boot time. Hardware breakpoints, “ba”, can be set at any time.
A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a03a387eb4cb97, Reserved
Arg2: b3b746bed1317254, Reserved
Arg3: fffff800012b4b40, Failure type dependent information
Arg4: 0000000000000001, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification

Debugging Details:

BUGCHECK_STR: 0x109

DEFAULT_BUCKET_ID: CODE_CORRUPTION

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff80001041910

STACK_TEXT:
fffffadfeb64eb88 0000000000000000 : 0000000000000109 a3a03a387eb4cb97 b3b746bed1317254 fffff800012b4b40 : nt!KeBugCheckEx

STACK_COMMAND: kb

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
fffff8000103a250-fffff8000103a25d 14 bytes - nt!DebugPrint
[45 8b c8 44 8b c2 66 8b:ff 25 00 00 00 00 8c b4]
fffff800012b4b40-fffff800012b4b4b 12 bytes - nt!NtCreateSection
[4c 89 44 24 18 89 54 24:48 b8 a0 f7 47 ea df fa]
26 errors : !nt (fffff8000103a250-fffff800012b4b4b)

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MEMORY_CORRUPTOR: LARGE

FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE

BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE

Followup: memory_corruption

kd> u nt!DebugPrint
nt!DebugPrint:
fffff8000103a250 ff2500000000 jmp qword ptr [nt!DebugPrint+0x6 (fffff8000103a256)]
fffff8000103a256 8cb424eadffaff mov word ptr [rsp-52016h],st(-2) fffff8000103a25d ff01 inc dword ptr [rcx]
fffff8000103a25f 0000 add byte ptr [rax],al fffff8000103a261 00cd add ch,cl
fffff8000103a263 2dccc3cccc sub eax,0CCCCC3CCh fffff8000103a268 cc int 3
fffff8000103a269 cc int 3 kd\> u poi(fffff8000103a256)
*** ERROR: Module load completed but symbols could not be loaded for Dbgv.sys
Dbgv+0x148c:
fffffadfea24b48c 48895c2408 mov qword ptr [rsp+8],rbx fffffadfea24b491 4889742410 mov qword ptr [rsp+10h],rsi
fffffadfea24b496 57 push rdi fffffadfea24b497 4883ec20 sub rsp,20h
fffffadfea24b49b 803dcb2c000000 cmp byte ptr [Dbgv+0x416d (fffffadfea24e16d)],0
fffffadfea24b4a2 418bf8 mov edi,r8d fffffadfea24b4a5 8bf2 mov esi,edx
fffffadf`ea24b4a7 488bd9 mov rbx,rcx

Ken_Johnson · November 20, 2009, 10:46pm

Yes, you’re not supposed to do that. Did you read the link mentioned in the !analyze -v output you posted?

S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Friday, November 20, 2009 7:28 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] about xp x64

Thanks!

If there is only nt!DebugPrint hook,we get no bluescreen!
But when I add nt!NtCreateSection hook, we get bluescreen in a moment!

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

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or data have been corrupted. There are generally three causes for a corruption:

A driver has inadvertently or deliberately modified critical kernel code or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
A developer attempted to set a normal kernel breakpoint using a kernel debugger that was not attached when the system was booted. Normal breakpoints, “bp”, can only be set if the debugger is attached at boot time. Hardware breakpoints, “ba”, can be set at any time.
A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a03a387eb4cb97, Reserved
Arg2: b3b746bed1317254, Reserved
Arg3: fffff800012b4b40, Failure type dependent information
Arg4: 0000000000000001, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification

Debugging Details:

BUGCHECK_STR: 0x109

DEFAULT_BUCKET_ID: CODE_CORRUPTION

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff80001041910

STACK_TEXT:
fffffadfeb64eb88 0000000000000000 : 0000000000000109 a3a03a387eb4cb97 b3b746bed1317254 fffff800012b4b40 : nt!KeBugCheckEx

STACK_COMMAND: kb

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
fffff8000103a250-fffff8000103a25d 14 bytes - nt!DebugPrint
[45 8b c8 44 8b c2 66 8b:ff 25 00 00 00 00 8c b4]
fffff800012b4b40-fffff800012b4b4b 12 bytes - nt!NtCreateSection
[4c 89 44 24 18 89 54 24:48 b8 a0 f7 47 ea df fa]
26 errors : !nt (fffff8000103a250-fffff800012b4b4b)

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MEMORY_CORRUPTOR: LARGE

FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE

BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE

Followup: memory_corruption

kd> u nt!DebugPrint
nt!DebugPrint:
fffff8000103a250 ff2500000000 jmp qword ptr [nt!DebugPrint+0x6 (fffff8000103a256)]
fffff8000103a256 8cb424eadffaff mov word ptr [rsp-52016h],st(-2) fffff8000103a25d ff01 inc dword ptr [rcx]
fffff8000103a25f 0000 add byte ptr [rax],al fffff8000103a261 00cd add ch,cl
fffff8000103a263 2dccc3cccc sub eax,0CCCCC3CCh fffff8000103a268 cc int 3
fffff8000103a269 cc int 3 kd\> u poi(fffff8000103a256)
*** ERROR: Module load completed but symbols could not be loaded for Dbgv.sys
Dbgv+0x148c:
fffffadfea24b48c 48895c2408 mov qword ptr [rsp+8],rbx fffffadfea24b491 4889742410 mov qword ptr [rsp+10h],rsi
fffffadfea24b496 57 push rdi fffffadfea24b497 4883ec20 sub rsp,20h
fffffadfea24b49b 803dcb2c000000 cmp byte ptr [Dbgv+0x416d (fffffadfea24e16d)],0
fffffadfea24b4a2 418bf8 mov edi,r8d fffffadfea24b4a5 8bf2 mov esi,edx
fffffadf`ea24b4a7 488bd9 mov rbx,rcx

NTDEV is sponsored by OSR

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

OSR_Community_User · November 20, 2009, 10:55pm

yes! i known patchguard.
but if there is only dbgview’s nt!DebugPrint hook, nothing happen!why???
and how to bypass xp x64 patchguard?
i only have something about bypass vista x64 patchguard

Gene_Soudlenkov · November 20, 2009, 11:01pm

This check happens at random, but after boot process is finished, you
have a couple of minutes - so if you want to hook something, you can do
it once and then unhook - so the patchguard won’t notice your intrusion.

xxxxx@gmail.com wrote:

yes! i known patchguard.
but if there is only dbgview’s nt!DebugPrint hook, nothing happen!why???
and how to bypass xp x64 patchguard?
i only have something about bypass vista x64 patchguard

NTDEV is sponsored by OSR

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

OSR_Community_User · November 20, 2009, 11:12pm

Through my observations:
dbgview.exe had hooked nt!DebugPrint and won’t unhook it! patchguard notice nothing.

i want to known how did it do that

Don_Burn_1 · November 21, 2009, 8:30am

The system provides special support for hooking DebugPrint. You cannot hook
anything else, welcome to wonderful world of hooking and why it is
discouraged.

–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

wrote in message news:xxxxx@ntdev…
> Through my observations:
> dbgview.exe had hooked nt!DebugPrint and won’t unhook it! patchguard
> notice nothing.
>
> i want to known how did it do that
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4626 (20091120)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

Information from ESET NOD32 Antivirus, version of virus signature database 4626 (20091120)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

James_Harper · November 21, 2009, 5:19pm

>

The system provides special support for hooking DebugPrint. You
cannot hook
anything else, welcome to wonderful world of hooking and why it is
discouraged.

Is there a ‘blessed’ way of doing this? Is it as simple as “spin all
other CPU’s at HIGH_LEVEL & replace a vector”?

I assume it’s only supported on systems where there is no other
‘blessed’ method of doing it?

Thanks

James

Ken_Johnson · November 21, 2009, 5:29pm

To clarify on this point a bit –

The mechanism DbgView uses on modern platforms isn’t hooking in the patching code sense, but just swapping a callback function pointer that is called when debug output is generated.

(No conspiracy here, just no one went through all of the trouble to get that particular extension point documented. I’ve no idea personally what you would really want to do with it that DbgView doesn’t do already, though, personally.)

S

-----Original Message-----
From: James Harper
Sent: Saturday, November 21, 2009 14:19
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] about xp x64

>
> The system provides special support for hooking DebugPrint. You
cannot hook
> anything else, welcome to wonderful world of hooking and why it is
> discouraged.
>

Is there a ‘blessed’ way of doing this? Is it as simple as “spin all
other CPU’s at HIGH_LEVEL & replace a vector”?

I assume it’s only supported on systems where there is no other
‘blessed’ method of doing it?

Thanks

James

—
NTDEV is sponsored by OSR

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

Mark_Roddy · November 21, 2009, 5:45pm

google DbgSetDebugPrintCallback. We’ve discussed this interface and
its lack of documentation and its lack of support on circa xp
platforms before.

DbgView is fine for some purposes but is not the be all and end all of
runtime kernel logging tools. For example, it would be ridiculous to
ask your customers to run dbgview and send you the output.

For xp you have no choice other than hooking DebugPrint. For now, on
vista and win7 based systems you can use the undocumented
DbgSetDebugPrintCallback - but as it is undocumented it could
disappear on a whim in future releases.

Mark Roddy

On Sat, Nov 21, 2009 at 5:28 PM, Skywing wrote:
> To clarify on this point a bit –
>
> The mechanism DbgView uses on modern platforms isn’t hooking in the patching code sense, but just swapping a callback function pointer that is called when debug output is generated.
>
> (No conspiracy here, just no one went through all of the trouble to get that particular extension point documented. ?I’ve no idea personally what you would really want to do with it that DbgView doesn’t do already, though, personally.)
>
> - S
>
> -----Original Message-----
> From: James Harper
> Sent: Saturday, November 21, 2009 14:19
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] about xp x64
>
>
>>
>> The system provides special support for hooking DebugPrint. ?You
> cannot hook
>> anything else, welcome to wonderful world of hooking and why it is
>> discouraged.
>>
>
> Is there a ‘blessed’ way of doing this? Is it as simple as “spin all
> other CPU’s at HIGH_LEVEL & replace a vector”?
>
> I assume it’s only supported on systems where there is no other
> ‘blessed’ method of doing it?
>
> Thanks
>
> James
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>
> 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
>

Ken_Johnson · November 21, 2009, 6:25pm

Yes, I’d probably go for something more flexible (log file, ETW) than DbgPrint for kernel logging if it’s going outside of a development environment and into a production/customer scenario. I’m sure Michal Vodicka has some thoughts on that point

S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Saturday, November 21, 2009 2:45 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] about xp x64

google DbgSetDebugPrintCallback. We’ve discussed this interface and
its lack of documentation and its lack of support on circa xp
platforms before.

DbgView is fine for some purposes but is not the be all and end all of
runtime kernel logging tools. For example, it would be ridiculous to
ask your customers to run dbgview and send you the output.

For xp you have no choice other than hooking DebugPrint. For now, on
vista and win7 based systems you can use the undocumented
DbgSetDebugPrintCallback - but as it is undocumented it could
disappear on a whim in future releases.

Mark Roddy

On Sat, Nov 21, 2009 at 5:28 PM, Skywing wrote:
> To clarify on this point a bit –
>
> The mechanism DbgView uses on modern platforms isn’t hooking in the patching code sense, but just swapping a callback function pointer that is called when debug output is generated.
>
> (No conspiracy here, just no one went through all of the trouble to get that particular extension point documented. ?I’ve no idea personally what you would really want to do with it that DbgView doesn’t do already, though, personally.)
>
> - S
>
> -----Original Message-----
> From: James Harper
> Sent: Saturday, November 21, 2009 14:19
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] about xp x64
>
>
>>
>> The system provides special support for hooking DebugPrint. ?You
> cannot hook
>> anything else, welcome to wonderful world of hooking and why it is
>> discouraged.
>>
>
> Is there a ‘blessed’ way of doing this? Is it as simple as “spin all
> other CPU’s at HIGH_LEVEL & replace a vector”?
>
> I assume it’s only supported on systems where there is no other
> ‘blessed’ method of doing it?
>
> Thanks
>
> James
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>
> 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

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

James_Harper · November 21, 2009, 8:00pm

>

google DbgSetDebugPrintCallback. We’ve discussed this interface and
its lack of documentation and its lack of support on circa xp
platforms before.

DbgView is fine for some purposes but is not the be all and end all of
runtime kernel logging tools. For example, it would be ridiculous to
ask your customers to run dbgview and send you the output.

I dump the DbgPrint logs out to the virtual machine host (Dom0 in
Xen-speak). For driver development, just being able to capture ASSERTs
makes things so much easier and is so much faster than attaching the
debugger. Someone mentioned some tools for synthesizing a memory dump
from the crashed machine state under Xen, which was useful for when
things crash so bad (or so early) that a crash dump isn’t possible.

James

Pavel_A1 · November 21, 2009, 8:44pm

“Mark Roddy” wrote in message news:xxxxx@ntdev…
…
> For example, it would be ridiculous to
> ask your customers to run dbgview and send you the output.

Mark, why asking customer to run DbgView would be worse than ask to setup a
trace session and send the trace log?

Regards,
–pa

Calvin_Guan-3 · November 21, 2009, 10:04pm

My guess is that with traceview, customer can’t see your dirty laundry which
may invite questions that you don’t want to answer.

Calvin Guan
Broadcom Corp.
Connecting Everything(r)

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Saturday, November 21, 2009 5:03 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] about xp x64

“Mark Roddy” wrote in message news:xxxxx@ntdev…
…
> For example, it would be ridiculous to
> ask your customers to run dbgview and send you the output.

Mark, why asking customer to run DbgView would be worse than ask to setup a
trace session and send the trace log?

Regards,
–pa

—
NTDEV is sponsored by OSR

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

OSR_Community_User · November 21, 2009, 10:22pm

And most driver release versions don’t have debug prints where an ETW trace
session does have trace outputs.

Bill Wandel

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of Calvin Guan
Sent: Saturday, November 21, 2009 10:04 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] about xp x64

My guess is that with traceview, customer can’t see your dirty laundry which
may invite questions that you don’t want to answer.

Calvin Guan
Broadcom Corp.
Connecting Everything(r)

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Saturday, November 21, 2009 5:03 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] about xp x64

“Mark Roddy” wrote in message news:xxxxx@ntdev…
…
> For example, it would be ridiculous to ask your customers to run
> dbgview and send you the output.

Mark, why asking customer to run DbgView would be worse than ask to setup a
trace session and send the trace log?

Regards,
–pa

—
NTDEV is sponsored by OSR

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

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

OSR_Community_User · November 22, 2009, 12:15am

thanks all!

hi,Don Burn:
What materials can be shown that
“The system provides special support for hooking DebugPrint. You cannot hook anything else”

OSR_Community_User · November 23, 2009, 4:44am

On 11/22/2009 6:17 AM, xxxxx@gmail.com wrote:

What materials can be shown that “The system provides special support
for hooking DebugPrint. You cannot hook anything else”

The link that is given in the debug output you posted on 2009-11-21

A driver has inadvertently or deliberately modified critical
kernel code or data. See
http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx

contains an explanation. As you obviously can not access the MSDN web
site, here is the relevant excerpt:

The x64-based versions of Microsoft Windows Server 2003 , Windows XP
Professional x64 Edition, and later versions of Windows for
x64-based systems do not allow the kernel to be patched except
through authorized Microsoft-originated hot patches.

[…]

If the operating system detects one of these modifications or any
other unauthorized patch, it will generate a bug check and shut down
the system.

[…]

If your driver must perform a task that you think cannot be
accomplished without patching the kernel, then contact
xxxxx@Microsoft.com for help in finding a documented and supported
alternative.

Please also see:
http://catb.org/~esr/faqs/smart-questions.html