What happens after return of DrvEscape and in the implementation of ExtEscape API

NTDEV
1

Hi Hi Hi there,

I am using ExtEscape() to get a DisplayDriver specific service (In this case
ist’s just a some driver data).

typedef struct _XXX_ARGS {

/*IN*/ ULONG Cmd;

/*IN*/ USHORT Action;

/*IN*/ WCHAR pwszValueName[64];

/*IN*/ /*OUT*/ DWORD dwValue;

/*OUT*/ NTSTATUS Status;
} XXX_ARGS, *PXXX_ARGS;

HDC hDC = CreateDC(“DISPLAY”,NULL,NULL,NULL);

XXX_ARGS xxxArgs;

xxxArgs.Action = GET_XXX_VALUE;

xxxArgs.Cmd = XXX_DWORD;

wcscpy(xxxArgs.pwszValueName, “xxxValue”);

cbIn=sizeof(XXX_ARGS);

retval = ExtEscape(hDC, XXX_ESCAPE, cbIn, (LPCSTR) &xxxArgs, cbIn, (LPSTR)
&xxxArgs);

and as expected it’s properly hitting DrvEscape gets in the required data in
to pvOut

*ULONG
**DrvEscape**(*
*IN SURFOBJ* **pso**,*
*IN ULONG* *iEsc**,*
*IN ULONG* *cjIn**,*
*IN PVOID* *pvIn**,*
*IN ULONG* *cjOut**,*
*OUT PVOID* *pvOut*
* );*

**

when I checked values at (XXX_ARGS*)pvOut.

pvOut->dwValue was 0x023C;

problem is when I checked the values after the call to ExtEscape()

xxxArgs->dwValue was 000000.

How can that happen.

I was wondering What happens after return of DrvEscape and in the
implementation of ExtEscape API?

Please help me.

regards,

Madhu

2

Madhusudan Narayan wrote:

I am using ExtEscape() to get a DisplayDriver specific service (In
this case ist’s just a some driver data).

typedef
struct _XXX_ARGS { /*IN*/ ULONG Cmd; /*IN*/ USHORT Action; /*IN*/
WCHAR pwszValueName[64]; /*IN*/ /*OUT*/ DWORD dwValue; /*OUT*/
NTSTATUS Status;
} XXX_ARGS, *PXXX_ARGS;

HDC hDC = CreateDC(“DISPLAY”,NULL,NULL,NULL);

XXX_ARGS xxxArgs;

xxxArgs.Action = GET_XXX_VALUE;

xxxArgs.Cmd = XXX_DWORD;

wcscpy(xxxArgs.pwszValueName,“xxxValue”);

I assumes that’s a typo, and you really had L"xxxValue", not “xxxValue”.

cbIn=sizeof(XXX_ARGS);

retval = ExtEscape(hDC, XXX_ESCAPE, cbIn, (LPCSTR) &xxxArgs, cbIn,
(LPSTR) &xxxArgs);

and as expected it’s properly hitting DrvEscape gets in the required
data in to pvOut

*…*

when I checked values at (XXX_ARGS*)pvOut.

pvOut->dwValue was 0x023C;

problem is when I checked the values after the call to ExtEscape()

xxxArgs->dwValue was 000000.

How can that happen.

What value do you return from DrvEscape? If you return 0, the system
may assume that the code was invalid and skip the copy back to user
mode. What numbers do you use for your escape codes? Values under
0x10000 are reserved for Microsoft, and some of them have hard-coded
meanings within GDI that can override your processing.

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

3

The return value from ExtEscape is 1.

And the escape code is 0x00439064.

On 2/26/07, Tim Roberts wrote:
>
> Madhusudan Narayan wrote:
> >
> > I am using ExtEscape() to get a DisplayDriver specific service (In
> > this case ist’s just a some driver data).
> >
> > typedef
> > struct _XXX_ARGS { /IN/ ULONG Cmd; /IN/ USHORT Action; /IN/
> > WCHAR pwszValueName[64]; /IN/ /OUT/ DWORD dwValue; /OUT/
> > NTSTATUS Status;
> > } XXX_ARGS, PXXX_ARGS;
> >
> >
> > HDC hDC = CreateDC(“DISPLAY”,NULL,NULL,NULL);
> >
> > XXX_ARGS xxxArgs;
> >
> > xxxArgs.Action = GET_XXX_VALUE;
> >
> > xxxArgs.Cmd = XXX_DWORD;
> >
> > wcscpy(xxxArgs.pwszValueName,“xxxValue”);
> >
>
> I assumes that’s a typo, and you really had L"xxxValue", not “xxxValue”.
>
> > cbIn=sizeof(XXX_ARGS);
> >
> > retval = ExtEscape(hDC, XXX_ESCAPE, cbIn, (LPCSTR) &xxxArgs, cbIn,
> > (LPSTR) &xxxArgs);
> >
> > and as expected it’s properly hitting DrvEscape gets in the required
> > data in to pvOut
> >
> > …
> >
> > when I checked values at (XXX_ARGS)pvOut.
> >
> > pvOut->dwValue was 0x023C;
> >
> > problem is when I checked the values after the call to ExtEscape()
> >
> > xxxArgs->dwValue was 000000.
> >
> > How can that happen.
> >
>
> What value do you return from DrvEscape? If you return 0, the system
> may assume that the code was invalid and skip the copy back to user
> mode. What numbers do you use for your escape codes? Values under
> 0x10000 are reserved for Microsoft, and some of them have hard-coded
> meanings within GDI that can override your processing.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

4

Madhusudan Narayan wrote:

The return value from ExtEscape is 1.

That’s not what I asked. I asked what the driver’s DrvEscape call returned.

And the escape code is 0x00439064.

I don’t know of any reason why that wouldn’t work. You may have to
trace back through win32k.sys to see what’s going on.

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

5

Thank you all for your help.

Anees figuried out that the issue was happening because the structure being
used by the app was not “packed” while the DrvEscape was filling the data to
a packed structure.
#pragma pack(1) before the structure definition in the app solved the
problem.

-Madhusudan

On 2/27/07, Tim Roberts wrote:
>
> Madhusudan Narayan wrote:
> > The return value from ExtEscape is 1.
>
> That’s not what I asked. I asked what the driver’s DrvEscape call
> returned.
>
>
> > And the escape code is 0x00439064.
>
> I don’t know of any reason why that wouldn’t work. You may have to
> trace back through win32k.sys to see what’s going on.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>