GDI bitmaps and WOW64 apps

Hello all,

I’m porting a virtual printer driver from Win32 to Win64 (WinXP for IA64,
to be more specific)
and recently I encountered a thorny issue - printing from native 64-bit
applications works
fine, but when trying to print from a 32-bit app running on WOW64, a stop
error is issued…

Here’s the WinDbg output when opening the crash dump:

KMODE_EXCEPTION_NOT_HANDLED (1e)
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.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: e00000008311db10, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: 000006fbff100040, Parameter 1 of the exception

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
referenced memory at “0x%08lx”. The memory could not be “%s”.

FAULTING_IP:
nt!RtlCopyMemoryNonTemporal+380
e0000000`8311db10 ld8 r19=[r33], 10

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: 000006fbff100040

READ_ADDRESS: Page 2800 not present in the dump file. Type “.hh dbgerr004”
for details
000006fbff100040

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x1E

TRAP_FRAME: e0000165db3070d0 – (.trap e0000165db3070d0)
f6 (ft0) = 0000000000000001 0000000000000000
f7 (ft1) = 000000000001003e 2aaaaaaaaaaaaaab
f8 (ft2) = 000000000001003e 0000000000000004
f9 (ft3) = 000000000000ffdd 8000000000000000
f10 (ft3) = 000000000000fff9 ffffc00000000000
f11 (ft4) = 000000000001003e 0000000000001000
f12 (ft5) = 000000000000ffe8 b206a9c000000000
f13 (ft6) = 000000000000ffea e2e1000000000000
f14 (ft7) = 0000000000010010 89fd000000000000
f15 (ft8) = 000000000001000e c8f5000000000000
unat = 0000000000000000 ccv = e0000165db307400
dcr = 0000000000007f05 preds = 0000000000009d05
rsc = 000000a800000003 rnat = ??? ???
bspstore=??? ???
bsp = e0000165db3085d0 Real bsp = e0000165db3084c0
r1 (gp) = e0000000833bf700 r2 (t0) = 0000000000000000
r3 (t1) = 0000000000000000 r8 (v0) = 0000000001680000
r9 (t2) = 0000000000000000 r10 (t3) = 000006fbff1000c0
r11 (t4) = 000006fbff100160 r12 (sp) = e0000165db307410
r13 (teb) = 000000007fff8000 r14 (t5) = e0000165db307400
r15 (t6) = 0000000000000008 r16 (t7) = 000006fbff100048
r17 (t8) = 0000000001680008 r18 (t9) = 0000000000101d00
r19 (t10) = 0000000000800000 r20 (t11) = e00001060090f430
r21 (t12) = 0000000000000000 r22 (t13) = 0000000000101d00
r23 (t14) = 0009804c0270033f r24 (t15) = 0000000000007f05
r25 (t16) = ffffffffff9a0000 r26 (t17) = 000000000000050d
r27 (t18) = e00001060090f428 r28 (t19) = e00001060090f400
r29 (t20) = ffffffffff9a0000 r30 (t21) = 000006fbff201d40
r31 (t22) = e00001060090f400
r32 = 0000000001680000 r33 = 000006fbff100040
r34 = 0000000000101d00 r35 = 20000001ff2f8fa0
r36 = 000000000000050d r37 = e00001060115a690
r38 = 000000000000050d r39 = 20000001ff711680
r40 = e00001060115a690 r41 = 0000000001020000
r42 = 0000000000000103 r43 = 20000001ff711680
r44 = 20000001ff1b7460 r45 = 0000000000000205
r46 = e0000000833bf700 r47 = 0000000000000001
r48 = e00000008690b252 r49 = 20000001ff1b7430
r50 = 0000000000000205 r51 = e0000000833bf700
r52 = e0000165db307400 r53 = 0000000000000000
r54 = 20000001ff2ddd20 r55 = 000000000000048d
r56 = 20000001ff711680 r57 = e0000165db307400
r58 = 20000001ff2dd4f0 r59 = 0000000000000996
r60 = 20000001ff711680 r61 = 20000001ff2aa460
r62 = 0000000000000204 r63 = e0000000833bf700
r64 = 0000000000008e45 r65 = 0000000000000000

b0 (brrp) = 20000001ff2f8fc0
b6 (brt0) = e000000083145a20
b7 (brt1) = e00000008311d790
nats = 0000000000000000
pfs = 000000000000050d
ipsr = 0000101008226018
isr = 0000080400000000
ifa = 000006fbff100040
iip = e00000008311db10
iipa = e00000008311db00
ifs = 8000000000011122
iim = 0000000000080014
iha = 00000000781bc000
fpsr = 0270033f
oldirql = 7fffe000
previousmode = 00000000
trapframe = 00000000
Trap Type: exception

nt!RtlCopyMemoryNonTemporal+0x380
e0000000`8311db10 ld8 r19=[r33], 10
Resetting default scope

LAST_CONTROL_TRANSFER: from 20000001ff2f8fc0 to e00000008311db10

STACK_TEXT:
e0000165db307410 e0000165db3084c0 20000001ff2f8fc0 : 0000000001680000
000006fbff100040 0000000000101d00 20000001ff2f8fa0 : nt!RtlCopyMemoryNonTemporal+0x380 e0000165db307410 e0000165db308470 20000001ff3d6700 : e00001060115a690 e0000165db307420 0000000000101d00 0000000001020000 :
win32k!UMPDOBJ::ThunkMemBlock+0xa0
e0000165db307410 e0000165db308420 20000001ff3ddb40 : e00001060115a690
e00001060115a6c0 e0000165db307470 0000000000000000 : win32k!UMPDOBJ::pso+0x100 e0000165db307420 e0000165db308358 20000001ff1d1b70 : e000010600f2b448 e0000106010632e0 0000000000000002 0000000000000001 :
win32k!UMPDDrvStartDoc+0x240
e0000165db307480 e0000165db3082b8 20000001ff1d26d0 : 000000001b2102f5
ffffffffffffffff e000010600f2b430 0000000000000002 : win32k!GreStartDocInternal+0x450 e0000165db307550 e0000165db3081f0 e000000083198670 : e0000106010632e0 0000000000000000 00000000003df0d8 e00001060115ac90 :
win32k!NtGdiStartDoc+0x930
e0000165db3075c0 e0000165db3081b0 000000006b30b6b0 : 0000000000000014
0ff000002f5b07a5 0ff000002f5b07a5 0ff000002f5b07a5 : nt!KiSystemServiceExit 000000000012e900 00000000001303b0 000000006b30b6b0 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x6b30b6b0

FOLLOWUP_IP:
win32k!UMPDOBJ::ThunkMemBlock+a0
20000001`ff2f8fc0 st8 [r33]=r35

SYMBOL_STACK_INDEX: 1

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: win32k!UMPDOBJ::ThunkMemBlock+a0

MODULE_NAME: win32k

IMAGE_NAME: win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3ec9142c

STACK_COMMAND: .trap e0000165db3070d0 ; kb

BUCKET_ID: 0x1E_win32k!UMPDOBJ::ThunkMemBlock+a0

The interesting thing here is that the address of the read access
exception (0x6fbff100040) is the address of
the surface bitmap bits - this memory zone is previously allocated by a
call to EngAllocMem(), then passed in to
EngCreateBitmap().

I tried all kinds of memory allocation functions (even to pass NULL to
EngCreateBitmap to let GDI handle the
allocation) , but the problem persists (although sometimes when using
pointers under the 32-bit barrier (i.e. the high 32 bits are 0 -
allocated with VirtualAlloc()) - it works - maybe the call to UMPDOBJ::ThunkMemBlock is skipped?)

Anyway, a solution would be to use a device-managed surface (as in the MS
Plotter sample) - this seems to work
but is not acceptable for our driver (which sometimes relies on GDI to
handle some operations).

I also tried the EngCreateDeviceSurface()/EngModifySurface() method
suggested in the DDK documentation,
but discovered in no time (when linking) that EngModifySurface() isn’t
available for user-mode drivers… :frowning:

If anyone has any advice about this issue, I’d be most grateful if you can
share it - after almost a week of ‘digging’ I
had quite enough of it and I’m increasingly more convinced that is a
Microsoft issue… but, just as well, I may not be…

Either way, thanks a lot and

Regards,
Alex

You have got to be kidding. Try again using plain text and you might get a
response.

=====================
Mark Roddy


From: xxxxx@saguaro.ro [mailto:xxxxx@saguaro.ro]
Sent: Wednesday, January 21, 2004 1:18 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] GDI bitmaps and WOW64 apps

Hello all,

I’m porting a virtual printer driver from Win32 to Win64 (WinXP for IA64, to
be more specific)
and recently I encountered a thorny issue - printing from native 64-bit
applications works
fine, but when trying to print from a 32-bit app running on WOW64, a stop
error is issued…

Here’s the WinDbg output when opening the crash dump:

KMODE_EXCEPTION_NOT_HANDLED (1e)
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.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: e00000008311db10, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: 000006fbff100040, Parameter 1 of the exception

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
referenced memory at “0x%08lx”. The memory could not be “%s”.

FAULTING_IP:
nt!RtlCopyMemoryNonTemporal+380
e0000000`8311db10 ld8 r19=[r33], 10

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: 000006fbff100040

READ_ADDRESS: Page 2800 not present in the dump file. Type “.hh dbgerr004”
for details
000006fbff100040

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x1E

TRAP_FRAME: e0000165db3070d0 – (.trap e0000165db3070d0)
f6 (ft0) = 0000000000000001 0000000000000000
f7 (ft1) = 000000000001003e 2aaaaaaaaaaaaaab
f8 (ft2) = 000000000001003e 0000000000000004
f9 (ft3) = 000000000000ffdd 8000000000000000
f10 (ft3) = 000000000000fff9 ffffc00000000000
f11 (ft4) = 000000000001003e 0000000000001000
f12 (ft5) = 000000000000ffe8 b206a9c000000000
f13 (ft6) = 000000000000ffea e2e1000000000000
f14 (ft7) = 0000000000010010 89fd000000000000
f15 (ft8) = 000000000001000e c8f5000000000000
unat = 0000000000000000 ccv = e0000165db307400
dcr = 0000000000007f05 preds = 0000000000009d05
rsc = 000000a800000003 rnat = ??? ???
bspstore=??? ???
bsp = e0000165db3085d0 Real bsp = e0000165db3084c0
r1 (gp) = e0000000833bf700 r2 (t0) = 0000000000000000

r3 (t1) = 0000000000000000 r8 (v0) = 0000000001680000

r9 (t2) = 0000000000000000 r10 (t3) =
000006fbff1000c0
r11 (t4) = 000006fbff100160 r12 (sp) =
e0000165db307410
r13 (teb) = 000000007fff8000 r14 (t5) =
e0000165db307400
r15 (t6) = 0000000000000008 r16 (t7) =
000006fbff100048
r17 (t8) = 0000000001680008 r18 (t9) =
0000000000101d00
r19 (t10) = 0000000000800000 r20 (t11) =
e00001060090f430
r21 (t12) = 0000000000000000 r22 (t13) =
0000000000101d00
r23 (t14) = 0009804c0270033f r24 (t15) =
0000000000007f05
r25 (t16) = ffffffffff9a0000 r26 (t17) =
000000000000050d
r27 (t18) = e00001060090f428 r28 (t19) =
e00001060090f400
r29 (t20) = ffffffffff9a0000 r30 (t21) =
000006fbff201d40
r31 (t22) = e00001060090f400
r32 = 0000000001680000 r33 =
000006fbff100040
r34 = 0000000000101d00 r35 =
20000001ff2f8fa0
r36 = 000000000000050d r37 =
e00001060115a690
r38 = 000000000000050d r39 =
20000001ff711680
r40 = e00001060115a690 r41 =
0000000001020000
r42 = 0000000000000103 r43 =
20000001ff711680
r44 = 20000001ff1b7460 r45 =
0000000000000205
r46 = e0000000833bf700 r47 =
0000000000000001
r48 = e00000008690b252 r49 =
20000001ff1b7430
r50 = 0000000000000205 r51 =
e0000000833bf700
r52 = e0000165db307400 r53 =
0000000000000000
r54 = 20000001ff2ddd20 r55 =
000000000000048d
r56 = 20000001ff711680 r57 =
e0000165db307400
r58 = 20000001ff2dd4f0 r59 =
0000000000000996
r60 = 20000001ff711680 r61 =
20000001ff2aa460
r62 = 0000000000000204 r63 =
e0000000833bf700
r64 = 0000000000008e45 r65 =
0000000000000000

b0 (brrp) = 20000001ff2f8fc0
b6 (brt0) = e000000083145a20
b7 (brt1) = e00000008311d790
nats = 0000000000000000
pfs = 000000000000050d
ipsr = 0000101008226018
isr = 0000080400000000
ifa = 000006fbff100040
iip = e00000008311db10
iipa = e00000008311db00
ifs = 8000000000011122
iim = 0000000000080014
iha = 00000000781bc000
fpsr = 0270033f
oldirql = 7fffe000
previousmode = 00000000
trapframe = 00000000
Trap Type: exception

nt!RtlCopyMemoryNonTemporal+0x380
e0000000`8311db10 ld8 r19=[r33], 10
Resetting default scope

LAST_CONTROL_TRANSFER: from 20000001ff2f8fc0 to e00000008311db10

STACK_TEXT:
e0000165db307410 e0000165db3084c0 20000001ff2f8fc0 : 0000000001680000
000006fbff100040 0000000000101d00 20000001ff2f8fa0 : nt!RtlCopyMemoryNonTemporal+0x380 e0000165db307410 e0000165db308470 20000001ff3d6700 : e00001060115a690 e0000165db307420 0000000000101d00 0000000001020000 :
win32k!UMPDOBJ::ThunkMemBlock+0xa0
e0000165db307410 e0000165db308420 20000001ff3ddb40 : e00001060115a690
e00001060115a6c0 e0000165db307470 0000000000000000 : win32k!UMPDOBJ::pso+0x100 e0000165db307420 e0000165db308358 20000001ff1d1b70 : e000010600f2b448 e0000106010632e0 0000000000000002 0000000000000001 :
win32k!UMPDDrvStartDoc+0x240
e0000165db307480 e0000165db3082b8 20000001ff1d26d0 : 000000001b2102f5
ffffffffffffffff e000010600f2b430 0000000000000002 : win32k!GreStartDocInternal+0x450 e0000165db307550 e0000165db3081f0 e000000083198670 : e0000106010632e0 0000000000000000 00000000003df0d8 e00001060115ac90 :
win32k!NtGdiStartDoc+0x930
e0000165db3075c0 e0000165db3081b0 000000006b30b6b0 : 0000000000000014
0ff000002f5b07a5 0ff000002f5b07a5 0ff000002f5b07a5 : nt!KiSystemServiceExit 000000000012e900 00000000001303b0 000000006b30b6b0 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x6b30b6b0

FOLLOWUP_IP:
win32k!UMPDOBJ::ThunkMemBlock+a0
20000001`ff2f8fc0 st8 [r33]=r35

SYMBOL_STACK_INDEX: 1

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: win32k!UMPDOBJ::ThunkMemBlock+a0

MODULE_NAME: win32k

IMAGE_NAME: win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3ec9142c

STACK_COMMAND: .trap e0000165db3070d0 ; kb

BUCKET_ID: 0x1E_win32k!UMPDOBJ::ThunkMemBlock+a0

The interesting thing here is that the address of the read access exception
(0x6fbff100040) is the address of
the surface bitmap bits - this memory zone is previously allocated by a call
to EngAllocMem(), then passed in to
EngCreateBitmap().

I tried all kinds of memory allocation functions (even to pass NULL to
EngCreateBitmap to let GDI handle the
allocation) , but the problem persists (although sometimes when using
pointers under the 32-bit barrier (i.e. the high 32 bits are 0 -
allocated with VirtualAlloc()) - it works - maybe the call to
UMPDOBJ::ThunkMemBlock is skipped?)

Anyway, a solution would be to use a device-managed surface (as in the MS
Plotter sample) - this seems to work
but is not acceptable for our driver (which sometimes relies on GDI to
handle some operations).

I also tried the EngCreateDeviceSurface()/EngModifySurface() method
suggested in the DDK documentation,
but discovered in no time (when linking) that EngModifySurface() isn’t
available for user-mode drivers… :frowning:

If anyone has any advice about this issue, I’d be most grateful if you can
share it - after almost a week of ‘digging’ I
had quite enough of it and I’m increasingly more convinced that is a
Microsoft issue… but, just as well, I may not be…

Either way, thanks a lot and

Regards,
Alex
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed to
ntdev as: xxxxx@stratus.com To unsubscribe send a blank email to
xxxxx@lists.osr.com