Hook NtGdiBitBlt,just add CAPTUREBLT,BSOD,in Win7(x86)

OSR_Community_User · August 12, 2010, 12:32pm

I hook the NtGdiBitBlt from shadowSSDT,in other OS(win2K,winXP,vista) is OK.
On win7(x86),it also OK in a lot of situations,but sometimes it will BSOD.
My NewNtGdiBitBlt is very simple:
DWORD NewNtGdiBitBlt(
HANDLE hDCDest,int XDest,int YDest,int Width,int Height,
HANDLE hDCSrc,int XSrc,int YSrc,
DWORD ROP,DWORD crBackColor,DWORD fl)
{
return ((NTGDIBITBLT)(OldNtGdiBitBlt)) (
hDCDest, XDest, YDest, Width, Height,
hDCSrc, XSrc, YSrc, ROP|CAPTUREBLT,
crBackColor,fl );
}

In my test,when BSOD,the hDCDest and hDCSrc both are DT_RASDISPLAY,and the hDCDest==hDCSrc.

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: c0000046, The exception code that was not handled
Arg2: 83e5b8f8, The address that the exception occurred at
Arg3: 9bf67618, Trap Frame
Arg4: 00000000

Debugging Details:

Page 60ea9 not present in the dump file. Type “.hh dbgerr004” for details
*** ERROR: Module load completed but symbols could not be loaded for LMEFS.sys
PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details
PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details

EXCEPTION_CODE: (NTSTATUS) 0xc0000046 -

FAULTING_IP:
nt!KeReleaseMutant+215
83e5b8f8 cc int 3

TRAP_FRAME: 9bf67618 – (.trap 0xffffffff9bf67618)
ESP EDITED! New esp=9bf679c8
ErrCode = 00000000
eax=c0000046 ebx=89a9c578 ecx=899b0b00 edx=00000000 esi=899b0b38 edi=00000000
eip=83e5b8f8 esp=9bf6768c ebp=9bf67a00 iopl=0 nv up ei ng nz na po nc
cs=0000 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000282
nt!KeReleaseMutant+0x215:
83e5b8f8 cc int 3
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: irsetup.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 83ed8382 to 83ef7d10

STACK_TEXT:
9bf67114 83ed8382 0000008e c0000046 83e5b8f8 nt!KeBugCheckEx+0x1e
9bf67534 83e4db08 9bf6796c 00000000 9bf67618 nt!KiDispatchException+0x1ac
9bf675e8 83e61fe7 9bf6796c 9bf6769c 00000000 nt!KiRaiseException+0x185
9bf67604 83e5e44a 9bf6796c 9bf6769c 00000000 nt!NtRaiseException+0x33
9bf67604 83e5b8f8 9bf6796c 9bf6769c 00000000 nt!KiFastCallEntry+0x12a
9bf67a00 83e5b6da 899b0b38 00000001 00000000 nt!KeReleaseMutant+0x215
9bf67a18 9b02ed93 899b0b38 00000000 9b02d2a5 nt!KeReleaseMutex+0x14
9bf67a24 9b02d2a5 ffb93748 9aff0aa9 00000000 win32k!W32PIDLOCK::vUnlockSingleThread+0xf
9bf67a2c 9aff0aa9 00000000 fda6f728 180108f6 win32k!SURFACE::bUnMap+0x1b
9bf67ba0 9b04c5e2 180108f6 00000017 00000003 win32k!GreStretchBltInternal+0x3fb
9bf67c98 9b034e1e 180108f6 00000017 00000003 win32k!NtGdiBitBltInternal+0x52
9bf67ccc 8c22535d 180108f6 00000017 00000003 win32k!NtGdiBitBlt+0x2f
WARNING: Stack unwind information not available. Following frames may be wrong.
9bf67d00 83e5e44a 180108f6 00000017 00000003 MyTestHook+0xa35d
9bf67d00 771364f4 180108f6 00000017 00000003 nt!KiFastCallEntry+0x12a
0012f0b0 00000000 00000000 00000000 00000000 0x771364f4

-----------------------------------------------------------
//
// MessageId: STATUS_MUTANT_NOT_OWNED
//
// MessageText:
//
// An attempt to release a mutant object was made by a thread that was not the owner of the mutant object.
//
#define STATUS_MUTANT_NOT_OWNED ((NTSTATUS)0xC0000046L)
-----------------------------------------------------------
anybody can clear it?thanks.
And what should I do?I’m crazy ~~~~~

Gregory_G_Dyess · August 12, 2010, 12:36pm

Patch Guard?

— xxxxx@hotmail.com wrote:

From: xxxxx@hotmail.com
To: “Windows System Software Devs Interest List”
Subject: [ntdev] Hook NtGdiBitBlt,just add CAPTUREBLT,BSOD,in Win7(x86)
Date: Thu, 12 Aug 2010 12:33:29 -0400 (EDT)

I hook the NtGdiBitBlt from shadowSSDT,in other OS(win2K,winXP,vista) is OK.
On win7(x86),it also OK in a lot of situations,but sometimes it will BSOD.
My NewNtGdiBitBlt is very simple:
DWORD NewNtGdiBitBlt(
HANDLE hDCDest,int XDest,int YDest,int Width,int Height,
HANDLE hDCSrc,int XSrc,int YSrc,
DWORD ROP,DWORD crBackColor,DWORD fl)
{
return ((NTGDIBITBLT)(OldNtGdiBitBlt)) (
hDCDest, XDest, YDest, Width, Height,
hDCSrc, XSrc, YSrc, ROP|CAPTUREBLT,
crBackColor,fl );
}

In my test,when BSOD,the hDCDest and hDCSrc both are DT_RASDISPLAY,and the hDCDest==hDCSrc.

-----------------------------------------------------------

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: c0000046, The exception code that was not handled
Arg2: 83e5b8f8, The address that the exception occurred at
Arg3: 9bf67618, Trap Frame
Arg4: 00000000

Debugging Details:
------------------

Page 60ea9 not present in the dump file. Type “.hh dbgerr004” for details
*** ERROR: Module load completed but symbols could not be loaded for LMEFS.sys
PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details
PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details

EXCEPTION_CODE: (NTSTATUS) 0xc0000046 -

FAULTING_IP:
nt!KeReleaseMutant+215
83e5b8f8 cc int 3

TRAP_FRAME: 9bf67618 – (.trap 0xffffffff9bf67618)
ESP EDITED! New esp=9bf679c8
ErrCode = 00000000
eax=c0000046 ebx=89a9c578 ecx=899b0b00 edx=00000000 esi=899b0b38 edi=00000000
eip=83e5b8f8 esp=9bf6768c ebp=9bf67a00 iopl=0 nv up ei ng nz na po nc
cs=0000 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000282
nt!KeReleaseMutant+0x215:
83e5b8f8 cc int 3
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: irsetup.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 83ed8382 to 83ef7d10

STACK_TEXT:
9bf67114 83ed8382 0000008e c0000046 83e5b8f8 nt!KeBugCheckEx+0x1e
9bf67534 83e4db08 9bf6796c 00000000 9bf67618 nt!KiDispatchException+0x1ac
9bf675e8 83e61fe7 9bf6796c 9bf6769c 00000000 nt!KiRaiseException+0x185
9bf67604 83e5e44a 9bf6796c 9bf6769c 00000000 nt!NtRaiseException+0x33
9bf67604 83e5b8f8 9bf6796c 9bf6769c 00000000 nt!KiFastCallEntry+0x12a
9bf67a00 83e5b6da 899b0b38 00000001 00000000 nt!KeReleaseMutant+0x215
9bf67a18 9b02ed93 899b0b38 00000000 9b02d2a5 nt!KeReleaseMutex+0x14
9bf67a24 9b02d2a5 ffb93748 9aff0aa9 00000000 win32k!W32PIDLOCK::vUnlockSingleThread+0xf
9bf67a2c 9aff0aa9 00000000 fda6f728 180108f6 win32k!SURFACE::bUnMap+0x1b
9bf67ba0 9b04c5e2 180108f6 00000017 00000003 win32k!GreStretchBltInternal+0x3fb
9bf67c98 9b034e1e 180108f6 00000017 00000003 win32k!NtGdiBitBltInternal+0x52
9bf67ccc 8c22535d 180108f6 00000017 00000003 win32k!NtGdiBitBlt+0x2f
WARNING: Stack unwind information not available. Following frames may be wrong.
9bf67d00 83e5e44a 180108f6 00000017 00000003 MyTestHook+0xa35d
9bf67d00 771364f4 180108f6 00000017 00000003 nt!KiFastCallEntry+0x12a
0012f0b0 00000000 00000000 00000000 00000000 0x771364f4

-----------------------------------------------------------
//
// MessageId: STATUS_MUTANT_NOT_OWNED
//
// MessageText:
//
// An attempt to release a mutant object was made by a thread that was not the owner of the mutant object.
//
#define STATUS_MUTANT_NOT_OWNED ((NTSTATUS)0xC0000046L)
-----------------------------------------------------------
anybody can clear it?thanks.
And what should I do?I’m crazy ~~~~~

—
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 · August 12, 2010, 1:03pm

He’s on x64; PatchGuard is x64 only. But it would certainly catch it, so this solution is invalid on x64 platforms.

Now let the tirades about the evils of hooking commence…

Ken

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gregory G Dyess
Sent: Thursday, August 12, 2010 10:36 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Hook NtGdiBitBlt,just add CAPTUREBLT,BSOD,in Win7(x86)

Patch Guard?

— xxxxx@hotmail.com wrote:

From: xxxxx@hotmail.com
To: “Windows System Software Devs Interest List”
Subject: [ntdev] Hook NtGdiBitBlt,just add CAPTUREBLT,BSOD,in Win7(x86)
Date: Thu, 12 Aug 2010 12:33:29 -0400 (EDT)

I hook the NtGdiBitBlt from shadowSSDT,in other OS(win2K,winXP,vista) is OK.
On win7(x86),it also OK in a lot of situations,but sometimes it will BSOD.
My NewNtGdiBitBlt is very simple:
DWORD NewNtGdiBitBlt(
HANDLE hDCDest,int XDest,int YDest,int Width,int Height,
HANDLE hDCSrc,int XSrc,int YSrc,
DWORD ROP,DWORD crBackColor,DWORD fl)
{
return ((NTGDIBITBLT)(OldNtGdiBitBlt)) (
hDCDest, XDest, YDest, Width, Height,
hDCSrc, XSrc, YSrc, ROP|CAPTUREBLT,
crBackColor,fl );
}

In my test,when BSOD,the hDCDest and hDCSrc both are DT_RASDISPLAY,and the hDCDest==hDCSrc.

-----------------------------------------------------------

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: c0000046, The exception code that was not handled
Arg2: 83e5b8f8, The address that the exception occurred at
Arg3: 9bf67618, Trap Frame
Arg4: 00000000

Debugging Details:
------------------

Page 60ea9 not present in the dump file. Type “.hh dbgerr004” for details
*** ERROR: Module load completed but symbols could not be loaded for LMEFS.sys PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details

EXCEPTION_CODE: (NTSTATUS) 0xc0000046 -

FAULTING_IP:
nt!KeReleaseMutant+215
83e5b8f8 cc int 3

TRAP_FRAME: 9bf67618 – (.trap 0xffffffff9bf67618) ESP EDITED! New esp=9bf679c8 ErrCode = 00000000
eax=c0000046 ebx=89a9c578 ecx=899b0b00 edx=00000000 esi=899b0b38 edi=00000000
eip=83e5b8f8 esp=9bf6768c ebp=9bf67a00 iopl=0 nv up ei ng nz na po nc
cs=0000 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000282
nt!KeReleaseMutant+0x215:
83e5b8f8 cc int 3
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: irsetup.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 83ed8382 to 83ef7d10

STACK_TEXT:
9bf67114 83ed8382 0000008e c0000046 83e5b8f8 nt!KeBugCheckEx+0x1e
9bf67534 83e4db08 9bf6796c 00000000 9bf67618 nt!KiDispatchException+0x1ac
9bf675e8 83e61fe7 9bf6796c 9bf6769c 00000000 nt!KiRaiseException+0x185
9bf67604 83e5e44a 9bf6796c 9bf6769c 00000000 nt!NtRaiseException+0x33
9bf67604 83e5b8f8 9bf6796c 9bf6769c 00000000 nt!KiFastCallEntry+0x12a
9bf67a00 83e5b6da 899b0b38 00000001 00000000 nt!KeReleaseMutant+0x215
9bf67a18 9b02ed93 899b0b38 00000000 9b02d2a5 nt!KeReleaseMutex+0x14
9bf67a24 9b02d2a5 ffb93748 9aff0aa9 00000000 win32k!W32PIDLOCK::vUnlockSingleThread+0xf
9bf67a2c 9aff0aa9 00000000 fda6f728 180108f6 win32k!SURFACE::bUnMap+0x1b
9bf67ba0 9b04c5e2 180108f6 00000017 00000003 win32k!GreStretchBltInternal+0x3fb
9bf67c98 9b034e1e 180108f6 00000017 00000003 win32k!NtGdiBitBltInternal+0x52 9bf67ccc 8c22535d 180108f6 00000017 00000003 win32k!NtGdiBitBlt+0x2f
WARNING: Stack unwind information not available. Following frames may be wrong.
9bf67d00 83e5e44a 180108f6 00000017 00000003 MyTestHook+0xa35d
9bf67d00 771364f4 180108f6 00000017 00000003 nt!KiFastCallEntry+0x12a
0012f0b0 00000000 00000000 00000000 00000000 0x771364f4

-----------------------------------------------------------
//
// MessageId: STATUS_MUTANT_NOT_OWNED
//
// MessageText:
//
// An attempt to release a mutant object was made by a thread that was not the owner of the mutant object.
//
#define STATUS_MUTANT_NOT_OWNED ((NTSTATUS)0xC0000046L)
-----------------------------------------------------------
anybody can clear it?thanks.
And what should I do?I’m crazy ~~~~~

—
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

Gary_Little-3 · August 12, 2010, 2:19pm

Gosh, no tirade, just a strong suggestion that the OP scrap the piece of crap they currently have and use a filter to do things properly. The amazing thing is that people with questions about hooking do not search the list first. If nothing else they would avoid a LOT of abuse.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Thursday, August 12, 2010 12:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hook NtGdiBitBlt,just add CAPTUREBLT,BSOD,in Win7(x86)

He’s on x64; PatchGuard is x64 only. But it would certainly catch it, so this solution is invalid on x64 platforms.

Now let the tirades about the evils of hooking commence…

Ken

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gregory G Dyess
Sent: Thursday, August 12, 2010 10:36 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Hook NtGdiBitBlt,just add CAPTUREBLT,BSOD,in Win7(x86)

Patch Guard?

— xxxxx@hotmail.com wrote:

From: xxxxx@hotmail.com
To: “Windows System Software Devs Interest List”
Subject: [ntdev] Hook NtGdiBitBlt,just add CAPTUREBLT,BSOD,in Win7(x86)
Date: Thu, 12 Aug 2010 12:33:29 -0400 (EDT)

I hook the NtGdiBitBlt from shadowSSDT,in other OS(win2K,winXP,vista) is OK.
On win7(x86),it also OK in a lot of situations,but sometimes it will BSOD.
My NewNtGdiBitBlt is very simple:
DWORD NewNtGdiBitBlt(
HANDLE hDCDest,int XDest,int YDest,int Width,int Height,
HANDLE hDCSrc,int XSrc,int YSrc,
DWORD ROP,DWORD crBackColor,DWORD fl)
{
return ((NTGDIBITBLT)(OldNtGdiBitBlt)) (
hDCDest, XDest, YDest, Width, Height,
hDCSrc, XSrc, YSrc, ROP|CAPTUREBLT,
crBackColor,fl );
}

In my test,when BSOD,the hDCDest and hDCSrc both are DT_RASDISPLAY,and the hDCDest==hDCSrc.

-----------------------------------------------------------

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: c0000046, The exception code that was not handled
Arg2: 83e5b8f8, The address that the exception occurred at
Arg3: 9bf67618, Trap Frame
Arg4: 00000000

Debugging Details:
------------------

Page 60ea9 not present in the dump file. Type “.hh dbgerr004” for details
*** ERROR: Module load completed but symbols could not be loaded for LMEFS.sys PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details

EXCEPTION_CODE: (NTSTATUS) 0xc0000046 -

FAULTING_IP:
nt!KeReleaseMutant+215
83e5b8f8 cc int 3

TRAP_FRAME: 9bf67618 – (.trap 0xffffffff9bf67618) ESP EDITED! New esp=9bf679c8 ErrCode = 00000000
eax=c0000046 ebx=89a9c578 ecx=899b0b00 edx=00000000 esi=899b0b38 edi=00000000
eip=83e5b8f8 esp=9bf6768c ebp=9bf67a00 iopl=0 nv up ei ng nz na po nc
cs=0000 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000282
nt!KeReleaseMutant+0x215:
83e5b8f8 cc int 3
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: irsetup.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 83ed8382 to 83ef7d10

STACK_TEXT:
9bf67114 83ed8382 0000008e c0000046 83e5b8f8 nt!KeBugCheckEx+0x1e
9bf67534 83e4db08 9bf6796c 00000000 9bf67618 nt!KiDispatchException+0x1ac
9bf675e8 83e61fe7 9bf6796c 9bf6769c 00000000 nt!KiRaiseException+0x185
9bf67604 83e5e44a 9bf6796c 9bf6769c 00000000 nt!NtRaiseException+0x33
9bf67604 83e5b8f8 9bf6796c 9bf6769c 00000000 nt!KiFastCallEntry+0x12a
9bf67a00 83e5b6da 899b0b38 00000001 00000000 nt!KeReleaseMutant+0x215
9bf67a18 9b02ed93 899b0b38 00000000 9b02d2a5 nt!KeReleaseMutex+0x14
9bf67a24 9b02d2a5 ffb93748 9aff0aa9 00000000 win32k!W32PIDLOCK::vUnlockSingleThread+0xf
9bf67a2c 9aff0aa9 00000000 fda6f728 180108f6 win32k!SURFACE::bUnMap+0x1b
9bf67ba0 9b04c5e2 180108f6 00000017 00000003 win32k!GreStretchBltInternal+0x3fb
9bf67c98 9b034e1e 180108f6 00000017 00000003 win32k!NtGdiBitBltInternal+0x52 9bf67ccc 8c22535d 180108f6 00000017 00000003 win32k!NtGdiBitBlt+0x2f
WARNING: Stack unwind information not available. Following frames may be wrong.
9bf67d00 83e5e44a 180108f6 00000017 00000003 MyTestHook+0xa35d
9bf67d00 771364f4 180108f6 00000017 00000003 nt!KiFastCallEntry+0x12a
0012f0b0 00000000 00000000 00000000 00000000 0x771364f4

-----------------------------------------------------------
//
// MessageId: STATUS_MUTANT_NOT_OWNED
//
// MessageText:
//
// An attempt to release a mutant object was made by a thread that was not the owner of the mutant object.
//
#define STATUS_MUTANT_NOT_OWNED ((NTSTATUS)0xC0000046L)
-----------------------------------------------------------
anybody can clear it?thanks.
And what should I do?I’m crazy ~~~~~

—
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

OSR_Community_User · August 12, 2010, 2:34pm

the BSOD is on X86!
don’t talking about patch guard~~~I know it.
on x86,we use Hook shadowSSDT;
on x64,we use inline hook in user-mode;

why don’t use the same skill on x86(inline hook in user-mode)?
It’s our history problem ~~~~

In this issue,I just want to know why the BSOD,not about Hook in X64.

Tim_Roberts · August 12, 2010, 4:55pm

xxxxx@hotmail.com wrote:

I hook the NtGdiBitBlt from shadowSSDT,in other OS(win2K,winXP,vista) is OK.
On win7(x86),it also OK in a lot of situations,but sometimes it will BSOD.
My NewNtGdiBitBlt is very simple:
DWORD NewNtGdiBitBlt(
HANDLE hDCDest,int XDest,int YDest,int Width,int Height,
HANDLE hDCSrc,int XSrc,int YSrc,
DWORD ROP,DWORD crBackColor,DWORD fl)
{
return ((NTGDIBITBLT)(OldNtGdiBitBlt)) (
hDCDest, XDest, YDest, Width, Height,
hDCSrc, XSrc, YSrc, ROP|CAPTUREBLT,
crBackColor,fl );
}

In my test,when BSOD,the hDCDest and hDCSrc both are DT_RASDISPLAY,and the hDCDest==hDCSrc.
…
Arguments:
Arg1: c0000046, The exception code that was not handled

CAPTUREBLT doesn’t make much sense in the screen-to-screen case.
Perhaps this is simply a restriction in the lower layers, and the upper
layers filter that out so that NtGdiBitBlt never sees it.

Since this is all undocumented, no one will be able to give you a real
answer. If I were you, I’d add an “if” statement to check for
hDCDest==hDCSrc and skip the CAPTUREBLT in that case.

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

OSR_Community_User · August 12, 2010, 11:38pm

> CAPTUREBLT doesn’t make much sense in the screen-to-screen case.

Perhaps this is simply a restriction in the lower layers, and the upper
layers filter that out so that NtGdiBitBlt never sees it.

Since this is all undocumented, no one will be able to give you a real
answer. If I were you, I’d add an “if” statement to check for
hDCDest==hDCSrc and skip the CAPTUREBLT in that case.

But in my test,when hDCDest==hDCSrc,it will BSOD sometimes,and it will be OK sometimes.
That’s to say,I think hDCDest==hDCSrc is not the key.

Scott_Noone_OSR · August 13, 2010, 9:54am

Tim summed this up quite nicely:

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Since this is all undocumented, no one will be able to give you a real
> answer.

You’re off in the weeds and running into the sorts of issues that happen
when dealing with hooking. I don’t think you’re going to get a better answer
here than, “no idea, hooking isn’t supported.”

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…
>> CAPTUREBLT doesn’t make much sense in the screen-to-screen case.
>> Perhaps this is simply a restriction in the lower layers, and the upper
>> layers filter that out so that NtGdiBitBlt never sees it.
>
>> Since this is all undocumented, no one will be able to give you a real
>> answer. If I were you, I’d add an “if” statement to check for
>> hDCDest==hDCSrc and skip the CAPTUREBLT in that case.
>
> But in my test,when hDCDest==hDCSrc,it will BSOD sometimes,and it will be
> OK sometimes.
> That’s to say,I think hDCDest==hDCSrc is not the key.
>