XDDM Mirror Driver under Windows 8

I am currently changing our mirror driver, which runs on systems up and until Windows 7, to run under Windows 8. To accomplish this I am changing the driver to conform to a Remote Display Driver as defined by Microsoft. This states that GCAPS2_REMOTEDRIVER be set in flGraphicsCaps. This is not defined in the Windows 7 DDK, but is in the Windows 8 DDK so I have made the assumption that the driver would need to be compiled under the Win 8 DDK?

Running a driver compiled under the 8 DDK I get a crash occurring somewhere in/near driver load that I can’t seem to trap in windbg. This driver does store some pointers to some functions like MajorFunction[IRP_MG_PNP] which to me are suspect. Are there any tricks to setting breakpoints in the supporting DLL? I am not sure if the dll is mapped into user space or kernel space by the GDI?

If I run a same driver code compiled under the 7 DDK, it will load and function when pointing to the primary display. Once I attempt to attach to a second display I appear to get screen updates from the primary display still but cursor updates for the second display. This has puzzled me, and if anyone has any insight here it would be greatly appreciated. Also, when the code recreates its surface for the second display, I have verified that the DevInfo.dmPosition is indeed correct.

I know I am trying to fix a suspension bridge here with dental floss; being that XDDM is really at its end with Windows 8. However I am hoping that getting it to conform to a Remote Display driver can buy me some time to determine which technology to replace it with.

The last question I have here is in reference to the definition of a Remote Display Driver, where it states that only a select few of the DrvXXX functions can be defined. Do they all need to be provided by the driver? or no more than what’s listed and it is up to the implementer to choose which?

Thanks,

Nik Twerdochlib
Software Developer

BOMGAR | The Box That’s Revolutionizing Remote Support™

One of the Fastest-Growing Technology Companies in America | Technology Fast 500™

What is Bomgar? Find out in 154 secondshttp:.</http:>

Nik Twerdochlib wrote:

I am currently changing our mirror driver, which runs on systems up
and until Windows 7, to run under Windows 8. To accomplish this I am
changing the driver to conform to a Remote Display Driver as defined
by Microsoft. This states that GCAPS2_REMOTEDRIVER be set in
flGraphicsCaps. This is not defined in the Windows 7 DDK, but is in
the Windows 8 DDK so I have made the assumption that the driver would
need to be compiled under the Win 8 DDK?

Yes.

Running a driver compiled under the 8 DDK I get a crash occurring
somewhere in/near driver load that I can’t seem to trap in windbg.
This driver does store some pointers to some functions like
MajorFunction[IRP_MG_PNP] which to me are suspect.

How do you do that? A display driver doesn’t have a DriverEntry or a
DRIVER_OBJECT, and it never sees IRPs. Are you talking about your miniport?

Are there any tricks to setting breakpoints in the supporting DLL? I
am not sure if the dll is mapped into user space or kernel space by
the GDI?

What supporting DLL do you mean? An XPDM driver set has a display
driver and a miniport, and both are kernel components.

The last question I have here is in reference to the definition of a
Remote Display Driver, where it states that only a select few of the
DrvXXX functions can be defined. Do they all need to be provided by
the driver? or no more than what’s listed and it is up to the
implementer to choose which?

That’s a fair question. Clearly, you can’t do anything outside of that
list, and I don’t see any on the list that you’d want to skip.


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

Nik Twerdochlib
Software Developer

BOMGAR | The Box That’s Revolutionizing Remote Support™

One of the Fastest-Growing Technology Companies in America | Technology Fast 500™
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, May 21, 2013 1:26 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] [nik] XDDM Mirror Driver under Windows 8

Nik Twerdochlib wrote:

I am currently changing our mirror driver, which runs on systems up
and until Windows 7, to run under Windows 8. To accomplish this I am
changing the driver to conform to a Remote Display Driver as defined
by Microsoft. This states that GCAPS2_REMOTEDRIVER be set in
flGraphicsCaps. This is not defined in the Windows 7 DDK, but is in
the Windows 8 DDK so I have made the assumption that the driver would
need to be compiled under the Win 8 DDK?

Yes.
[Nik Twerdochlib] Thank you for the confirmation.

Running a driver compiled under the 8 DDK I get a crash occurring
somewhere in/near driver load that I can’t seem to trap in windbg.
This driver does store some pointers to some functions like
MajorFunction[IRP_MG_PNP] which to me are suspect.

How do you do that? A display driver doesn’t have a DriverEntry or a DRIVER_OBJECT, and it never sees IRPs. Are you talking about your miniport?
[Nik Twerdochlib] This turned out to be a good question… More digging on my part found that the existing code base was also trying to support NT4, all of which has now been removed. This was in the mini port driver.

Are there any tricks to setting breakpoints in the supporting DLL? I
am not sure if the dll is mapped into user space or kernel space by
the GDI?

What supporting DLL do you mean? An XPDM driver set has a display driver and a miniport, and both are kernel components.
[Nik Twerdochlib] I was so tired when I wrote this… I had scan lines burned in my retinas from trying to figure out what was going on. Yes the crash occurs in the display driver and I have recently found the possible reason as to why and why it made no sense at all… I found that the project had local versions of certain DDK header files which were being included before any DDK versions. I am not sure if there were any local mods, but that has now been corrected. I am going to test an updated build that is actually using the correct DDK headers now. Knowing this now, the crash really exhibits the pattern for mismatched header files.

Also, it is good to confirm that the display driver is in kernel space. I might have been getting it crossed with WDDM which is now kept in user mode? (too much reading in too short of a time)

The last question I have here is in reference to the definition of a
Remote Display Driver, where it states that only a select few of the
DrvXXX functions can be defined. Do they all need to be provided by
the driver? or no more than what’s listed and it is up to the
implementer to choose which?

That’s a fair question. Clearly, you can’t do anything outside of that list, and I don’t see any on the list that you’d want to skip.
[Nik Twerdochlib] I have them all defined but I am wondering if there is something I can do regarding DrvGetModes. Currently there is a defined array of what appears to be some of the popular resolutions, but I would really rather not try and define these. Since for the mirror driver, the mode will never change (or at least we won’t change the display mode) I am wondering if there is a magic value, like -1, that can be returned stating current mode… which leads me to wonder if for the remote display driver if the mode really matters? The position and extents will be set in the DEVMODE structure by the user mode app.

[Nik Twerdochlib] Thank you again for the reply.

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


NTDEV is sponsored by OSR

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

Nik Twerdochlib wrote:

[Nik Twerdochlib] I have them all defined but I am wondering if there is something I can do regarding DrvGetModes. Currently there is a defined array of what appears to be some of the popular resolutions, but I would really rather not try and define these. Since for the mirror driver, the mode will never change (or at least we won’t change the display mode) I am wondering if there is a magic value, like -1, that can be returned stating current mode… which leads me to wonder if for the remote display driver if the mode really matters? The position and extents will be set in the DEVMODE structure by the user mode app.

The mirror driver sample (last seen in the 3790 DDK) does not define
DrvGetModes at all.


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

I did notice that, however I am not clear as to when the “Remote Display Driver” was defined. I have been able to compile the sample, even under VS 2012 but have not gotten it to load so I can test it.

Nik Twerdochlib
Software Developer

+1.601.607.8309 O
+1.866.522.8678 F

BOMGAR | The Box That’s Revolutionizing Remote Support™

One of the Fastest-Growing Technology Companies in America | Technology Fast 500™

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, May 21, 2013 4:41 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] [nik] XDDM Mirror Driver under Windows 8

Nik Twerdochlib wrote:

[Nik Twerdochlib] I have them all defined but I am wondering if there is something I can do regarding DrvGetModes. Currently there is a defined array of what appears to be some of the popular resolutions, but I would really rather not try and define these. Since for the mirror driver, the mode will never change (or at least we won’t change the display mode) I am wondering if there is a magic value, like -1, that can be returned stating current mode… which leads me to wonder if for the remote display driver if the mode really matters? The position and extents will be set in the DEVMODE structure by the user mode app.

The mirror driver sample (last seen in the 3790 DDK) does not define DrvGetModes at all.


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


NTDEV is sponsored by OSR

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

The following stack trace is from the crash I am running into. It is in the display driver, and hardcoded breakpoints I have set in DrvEnableDriver and DrvEnablePDEV do not get hit. I am kind of thinking that the entry point of DrvEnableDriver is not getting set correctly? This is under x64.

ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY (fc)
An attempt was made to execute non-executable memory. The guilty driver
is on the stack trace (and is typically the current instruction pointer).
When possible, the guilty driver’s name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: fffff96000a03000, Virtual address for the attempted execute.
Arg2: 800000006c585221, PTE contents.
Arg3: fffff88009110170, (reserved)
Arg4: 0000000000000002, (reserved)

Debugging Details:

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0xFC

PROCESS_NAME: bomgar-scc-x64

CURRENT_IRQL: 0

TRAP_FRAME: fffff88009110170 – (.trap 0xfffff88009110170)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff901006f59d0 rbx=0000000000000000 rcx=0000000000030101
rdx=0000000000000010 rsi=0000000000000000 rdi=0000000000000000
rip=fffff96000a03000 rsp=fffff88009110308 rbp=fffff88009110360
r8=fffff88009110340 r9=fffff96000a03000 r10=0000000000000000
r11=fffffa8003b2a8c0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
bgdspdrv_fffff96000a03000!MIRRSURF::MIRRSURF (bgdspdrv_fffff96000a03000+0x0):
fffff96000a03000 4d5a pop r10<br>Resetting default scope<br><br>LAST_CONTROL_TRANSFER: from fffff800b21ef28a to fffff800b20c6cf0<br><br>STACK_TEXT:<br>fffff8800910f788 fffff800b21ef28a : 0000000000000000 00000000000000fc fffff8800910f8f0 fffff800b213abc8 : nt!DbgBreakPointWithStatus<br>fffff8800910f790 fffff800b21ee8de : 0000000000000003 fffff8800910f8f0 fffff800b2134550 fffff8800910fe40 : nt!KiBugCheckDebugBreak+0x12<br>fffff8800910f7f0 fffff800b20cc544 : fffff901006f59d0 0000000000000000 0000000000000000 fffff800b215a3d7 : nt!KeBugCheck2+0x79f<br>fffff8800910ff10 fffff800b225e016 : 00000000000000fc fffff96000a03000 800000006c585221 fffff88009110170 : nt!KeBugCheckEx+0x104<br>fffff8800910ff50 fffff800b2132161 : 800000006c585221 0000000000000001 fffff88009110020 fffff88009110030 : nt! ?? ::FNODOBFM::string’+0x344e2
fffff8800910ff90 fffff800b2106acb : 0000000000000008 fffff96000a03000 fffffa8003b2a8c0 fffff88009110260 : nt!MiSystemFault+0x9a7
fffff88009110030 fffff800b20c9eee : 0000000000000008 fffff90104f2fc70 0000000000000000 fffff88009110170 : nt!MmAccessFault+0x55b
fffff88009110170 fffff96000a03000 : fffff9600021c8ec 0000000000000000 0000000000000000 fffff90104456ab0 : nt!KiPageFault+0x16e
fffff88009110308 fffff9600021c8ec : 0000000000000000 0000000000000000 fffff90104456ab0 fffff88009110360 : bgdspdrv_fffff96000a03000!MIRRSURF::MIRRSURF (bgdspdrv_fffff96000a03000+0x0)
fffff88009110310 fffff9600021c57d : 0000000000000000 0000000000000000 fffff88009110430 0000000000000000 : win32k!ldevLoadDriver+0x178
fffff88009110390 fffff9600021c2d2 : fffff90100725010 0000000000000000 fffff90104456a80 fffff960002004b5 : win32k!ldevGetDriverModes+0x45
fffff880091103e0 fffff9600021d6dc : 0000000000000000 0000000000000000 fffff880091106f0 0000000000000000 : win32k!DrvBuildDevmodeList+0x10e
fffff88009110430 fffff960002176fe : fffff90100725010 fffff88009110678 fffff88000000000 fffffa8000000000 : win32k!DrvProbeAndCaptureDevmode+0x534
fffff880091105f0 fffff9600021149b : 0000000000000001 0000000000000000 0000000000000000 0000000000000000 : win32k!DrvInternalChangeDisplaySettings+0x1f2
fffff88009110880 fffff960002672f2 : fffff90100582150 fffff901000b7010 0000000000000001 05bbc46000000004 : win32k!DrvChangeDisplaySettings+0xafb
fffff88009110a50 fffff96000266dee : 0000000000000000 00000000058feae0 0000000000000000 0000000000000000 : win32k!xxxInternalUserChangeDisplaySettings+0x212
fffff88009110b10 fffff96000266d11 : 00000000058feae0 00000000058febe0 0000000040000009 0000000040000009 : win32k!xxxUserChangeDisplaySettings+0xae
fffff88009110be0 fffff800b20cb453 : fffffa8003b2a8c0 fffff88009110cc0 0000000040000009 0000000000000924 : win32k!NtUserChangeDisplaySettings+0xb1
fffff88009110c40 000007fef330327a : 000007fef3304620 cccccccccccccccc 0000000000000030 cccccccccccccccc : nt!KiSystemServiceCopyEnd+0x13
00000000058feab8 000007fef3304620 : cccccccccccccccc 0000000000000030 cccccccccccccccc cccccccc00000001 : USER32!NtUserChangeDisplaySettings+0xa
00000000058feac0 000007f74c7bffa5 : 0000000000000000 0000000000000000 0000000000000000 00000000058fecbc : USER32!ChangeDisplaySettingsExW+0x50
00000000058feb00 0000000000000000 : 0000000000000000 0000000000000000 00000000058fecbc 0000000000000000 : bomgar_scc_x64!nstv::MirrorDriver::Connect+0x2d5 [f:\source\bomgar.git\networkstreaming\tunnelvision\src\win32\mirrordriver.cpp @ 197]

STACK_COMMAND: kb

FOLLOWUP_IP:
win32k!ldevLoadDriver+178
fffff960`0021c8ec 85c0 test eax,eax

SYMBOL_STACK_INDEX: 9

SYMBOL_NAME: win32k!ldevLoadDriver+178

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: win32k

IMAGE_NAME: win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 51637e38

BUCKET_ID_FUNC_OFFSET: 178

FAILURE_BUCKET_ID: 0xFC_win32k!ldevLoadDriver

BUCKET_ID: 0xFC_win32k!ldevLoadDriver

Followup: MachineOwner
---------

Am I way off base here in thinking that fffff96000a03000 is being treated as the entry point address? Reviewing the generated map file I don’t see an entry for DrvEnableDriver so that makes me think it is correct, but I am also noticing some additional settings that appear to be merging sections?

_TEXT=.text;_PAGE=PAGE

This project has been around since NT2K and I converted it with nmake2msbuild. I am also wondering if I have “inherited” some configuration that was needed back then and is just not compatible now. I need to probably step back and compare this project to the DDK7 mirror example. Possible take another stab at getting that to load.

Nik Twerdochlib
Software Developer

+1.601.607.8309 O
+1.866.522.8678 F

BOMGAR | The Box That’s Revolutionizing Remote Support™

One of the Fastest-Growing Technology Companies in America | Technology Fast 500™

What is Bomgar? Find out in 154 secondshttp:.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Nik Twerdochlib
Sent: Monday, May 20, 2013 10:38 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] [nik] XDDM Mirror Driver under Windows 8

I am currently changing our mirror driver, which runs on systems up and until Windows 7, to run under Windows 8. To accomplish this I am changing the driver to conform to a Remote Display Driver as defined by Microsoft. This states that GCAPS2_REMOTEDRIVER be set in flGraphicsCaps. This is not defined in the Windows 7 DDK, but is in the Windows 8 DDK so I have made the assumption that the driver would need to be compiled under the Win 8 DDK?

Running a driver compiled under the 8 DDK I get a crash occurring somewhere in/near driver load that I can’t seem to trap in windbg. This driver does store some pointers to some functions like MajorFunction[IRP_MG_PNP] which to me are suspect. Are there any tricks to setting breakpoints in the supporting DLL? I am not sure if the dll is mapped into user space or kernel space by the GDI?

If I run a same driver code compiled under the 7 DDK, it will load and function when pointing to the primary display. Once I attempt to attach to a second display I appear to get screen updates from the primary display still but cursor updates for the second display. This has puzzled me, and if anyone has any insight here it would be greatly appreciated. Also, when the code recreates its surface for the second display, I have verified that the DevInfo.dmPosition is indeed correct.

I know I am trying to fix a suspension bridge here with dental floss; being that XDDM is really at its end with Windows 8. However I am hoping that getting it to conform to a Remote Display driver can buy me some time to determine which technology to replace it with.

The last question I have here is in reference to the definition of a Remote Display Driver, where it states that only a select few of the DrvXXX functions can be defined. Do they all need to be provided by the driver? or no more than what’s listed and it is up to the implementer to choose which?

Thanks,

Nik Twerdochlib
Software Developer

BOMGAR | The Box That’s Revolutionizing Remote Support™

One of the Fastest-Growing Technology Companies in America | Technology Fast 500™

What is Bomgar? Find out in 154 secondshttp:.


NTDEV is sponsored by OSR

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</http:></http:>

Reviewing dumpbin output for a display driver compiled under VS2012 vs one compiled under DDK 7, I am finding that the DDK 8 driver does not have an entry point listed in the optional headers? I have confirmed that the project as one set. Is there something else I need to set?

Nik Twerdochlib
Software Developer

+1.601.607.8309 O
+1.866.522.8678 F

BOMGAR | The Box That’s Revolutionizing Remote Support™

One of the Fastest-Growing Technology Companies in America | Technology Fast 500™

What is Bomgar? Find out in 154 secondshttp:.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Nik Twerdochlib
Sent: Tuesday, May 21, 2013 4:52 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] [nik] XDDM Mirror Driver under Windows 8

The following stack trace is from the crash I am running into. It is in the display driver, and hardcoded breakpoints I have set in DrvEnableDriver and DrvEnablePDEV do not get hit. I am kind of thinking that the entry point of DrvEnableDriver is not getting set correctly? This is under x64.

ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY (fc)
An attempt was made to execute non-executable memory. The guilty driver
is on the stack trace (and is typically the current instruction pointer).
When possible, the guilty driver’s name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: fffff96000a03000, Virtual address for the attempted execute.
Arg2: 800000006c585221, PTE contents.
Arg3: fffff88009110170, (reserved)
Arg4: 0000000000000002, (reserved)

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

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0xFC

PROCESS_NAME: bomgar-scc-x64

CURRENT_IRQL: 0

TRAP_FRAME: fffff88009110170 – (.trap 0xfffff88009110170)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff901006f59d0 rbx=0000000000000000 rcx=0000000000030101
rdx=0000000000000010 rsi=0000000000000000 rdi=0000000000000000
rip=fffff96000a03000 rsp=fffff88009110308 rbp=fffff88009110360
r8=fffff88009110340 r9=fffff96000a03000 r10=0000000000000000
r11=fffffa8003b2a8c0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
bgdspdrv_fffff96000a03000!MIRRSURF::MIRRSURF (bgdspdrv_fffff96000a03000+0x0):
fffff96000a03000 4d5a pop r10<br>Resetting default scope<br><br>LAST_CONTROL_TRANSFER: from fffff800b21ef28a to fffff800b20c6cf0<br><br>STACK_TEXT:<br>fffff8800910f788 fffff800b21ef28a : 0000000000000000 00000000000000fc fffff8800910f8f0 fffff800b213abc8 : nt!DbgBreakPointWithStatus<br>fffff8800910f790 fffff800b21ee8de : 0000000000000003 fffff8800910f8f0 fffff800b2134550 fffff8800910fe40 : nt!KiBugCheckDebugBreak+0x12<br>fffff8800910f7f0 fffff800b20cc544 : fffff901006f59d0 0000000000000000 0000000000000000 fffff800b215a3d7 : nt!KeBugCheck2+0x79f<br>fffff8800910ff10 fffff800b225e016 : 00000000000000fc fffff96000a03000 800000006c585221 fffff88009110170 : nt!KeBugCheckEx+0x104<br>fffff8800910ff50 fffff800b2132161 : 800000006c585221 0000000000000001 fffff88009110020 fffff88009110030 : nt! ?? ::FNODOBFM::string’+0x344e2
fffff8800910ff90 fffff800b2106acb : 0000000000000008 fffff96000a03000 fffffa8003b2a8c0 fffff88009110260 : nt!MiSystemFault+0x9a7
fffff88009110030 fffff800b20c9eee : 0000000000000008 fffff90104f2fc70 0000000000000000 fffff88009110170 : nt!MmAccessFault+0x55b
fffff88009110170 fffff96000a03000 : fffff9600021c8ec 0000000000000000 0000000000000000 fffff90104456ab0 : nt!KiPageFault+0x16e
fffff88009110308 fffff9600021c8ec : 0000000000000000 0000000000000000 fffff90104456ab0 fffff88009110360 : bgdspdrv_fffff96000a03000!MIRRSURF::MIRRSURF (bgdspdrv_fffff96000a03000+0x0)
fffff88009110310 fffff9600021c57d : 0000000000000000 0000000000000000 fffff88009110430 0000000000000000 : win32k!ldevLoadDriver+0x178
fffff88009110390 fffff9600021c2d2 : fffff90100725010 0000000000000000 fffff90104456a80 fffff960002004b5 : win32k!ldevGetDriverModes+0x45
fffff880091103e0 fffff9600021d6dc : 0000000000000000 0000000000000000 fffff880091106f0 0000000000000000 : win32k!DrvBuildDevmodeList+0x10e
fffff88009110430 fffff960002176fe : fffff90100725010 fffff88009110678 fffff88000000000 fffffa8000000000 : win32k!DrvProbeAndCaptureDevmode+0x534
fffff880091105f0 fffff9600021149b : 0000000000000001 0000000000000000 0000000000000000 0000000000000000 : win32k!DrvInternalChangeDisplaySettings+0x1f2
fffff88009110880 fffff960002672f2 : fffff90100582150 fffff901000b7010 0000000000000001 05bbc46000000004 : win32k!DrvChangeDisplaySettings+0xafb
fffff88009110a50 fffff96000266dee : 0000000000000000 00000000058feae0 0000000000000000 0000000000000000 : win32k!xxxInternalUserChangeDisplaySettings+0x212
fffff88009110b10 fffff96000266d11 : 00000000058feae0 00000000058febe0 0000000040000009 0000000040000009 : win32k!xxxUserChangeDisplaySettings+0xae
fffff88009110be0 fffff800b20cb453 : fffffa8003b2a8c0 fffff88009110cc0 0000000040000009 0000000000000924 : win32k!NtUserChangeDisplaySettings+0xb1
fffff88009110c40 000007fef330327a : 000007fef3304620 cccccccccccccccc 0000000000000030 cccccccccccccccc : nt!KiSystemServiceCopyEnd+0x13
00000000058feab8 000007fef3304620 : cccccccccccccccc 0000000000000030 cccccccccccccccc cccccccc00000001 : USER32!NtUserChangeDisplaySettings+0xa
00000000058feac0 000007f74c7bffa5 : 0000000000000000 0000000000000000 0000000000000000 00000000058fecbc : USER32!ChangeDisplaySettingsExW+0x50
00000000058feb00 0000000000000000 : 0000000000000000 0000000000000000 00000000058fecbc 0000000000000000 : bomgar_scc_x64!nstv::MirrorDriver::Connect+0x2d5 [f:\source\bomgar.git\networkstreaming\tunnelvision\src\win32\mirrordriver.cpp @ 197]

STACK_COMMAND: kb

FOLLOWUP_IP:
win32k!ldevLoadDriver+178
fffff960`0021c8ec 85c0 test eax,eax

SYMBOL_STACK_INDEX: 9

SYMBOL_NAME: win32k!ldevLoadDriver+178

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: win32k

IMAGE_NAME: win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 51637e38

BUCKET_ID_FUNC_OFFSET: 178

FAILURE_BUCKET_ID: 0xFC_win32k!ldevLoadDriver

BUCKET_ID: 0xFC_win32k!ldevLoadDriver

Followup: MachineOwner
---------

Am I way off base here in thinking that fffff96000a03000 is being treated as the entry point address? Reviewing the generated map file I don’t see an entry for DrvEnableDriver so that makes me think it is correct, but I am also noticing some additional settings that appear to be merging sections?

_TEXT=.text;_PAGE=PAGE

This project has been around since NT2K and I converted it with nmake2msbuild. I am also wondering if I have “inherited” some configuration that was needed back then and is just not compatible now. I need to probably step back and compare this project to the DDK7 mirror example. Possible take another stab at getting that to load.

Nik Twerdochlib
Software Developer

+1.601.607.8309 O
+1.866.522.8678 F

BOMGAR | The Box That’s Revolutionizing Remote Support™

One of the Fastest-Growing Technology Companies in America | Technology Fast 500™

What is Bomgar? Find out in 154 secondshttp:.
From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.com] On Behalf Of Nik Twerdochlib
Sent: Monday, May 20, 2013 10:38 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] [nik] XDDM Mirror Driver under Windows 8

I am currently changing our mirror driver, which runs on systems up and until Windows 7, to run under Windows 8. To accomplish this I am changing the driver to conform to a Remote Display Driver as defined by Microsoft. This states that GCAPS2_REMOTEDRIVER be set in flGraphicsCaps. This is not defined in the Windows 7 DDK, but is in the Windows 8 DDK so I have made the assumption that the driver would need to be compiled under the Win 8 DDK?

Running a driver compiled under the 8 DDK I get a crash occurring somewhere in/near driver load that I can’t seem to trap in windbg. This driver does store some pointers to some functions like MajorFunction[IRP_MG_PNP] which to me are suspect. Are there any tricks to setting breakpoints in the supporting DLL? I am not sure if the dll is mapped into user space or kernel space by the GDI?

If I run a same driver code compiled under the 7 DDK, it will load and function when pointing to the primary display. Once I attempt to attach to a second display I appear to get screen updates from the primary display still but cursor updates for the second display. This has puzzled me, and if anyone has any insight here it would be greatly appreciated. Also, when the code recreates its surface for the second display, I have verified that the DevInfo.dmPosition is indeed correct.

I know I am trying to fix a suspension bridge here with dental floss; being that XDDM is really at its end with Windows 8. However I am hoping that getting it to conform to a Remote Display driver can buy me some time to determine which technology to replace it with.

The last question I have here is in reference to the definition of a Remote Display Driver, where it states that only a select few of the DrvXXX functions can be defined. Do they all need to be provided by the driver? or no more than what’s listed and it is up to the implementer to choose which?

Thanks,

Nik Twerdochlib
Software Developer

BOMGAR | The Box That’s Revolutionizing Remote Support™

One of the Fastest-Growing Technology Companies in America | Technology Fast 500™

What is Bomgar? Find out in 154 secondshttp:.


NTDEV is sponsored by OSR

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

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</http:></mailto:xxxxx></http:></http:>

So is it possible that nmake2msbuild conversion utility add the /NOENTRY to the linker command line? I see that this is set on two different projects that I have converted and removing it allows the intended entry point to be set.

Nik Twerdochlib
Software Developer

BOMGAR | The Box That’s Revolutionizing Remote Support™

One of the Fastest-Growing Technology Companies in America | Technology Fast 500™

What is Bomgar? Find out in 154 secondshttp:.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Nik Twerdochlib
Sent: Wednesday, May 22, 2013 9:39 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] [nik] XDDM Mirror Driver under Windows 8

Reviewing dumpbin output for a display driver compiled under VS2012 vs one compiled under DDK 7, I am finding that the DDK 8 driver does not have an entry point listed in the optional headers? I have confirmed that the project as one set. Is there something else I need to set?

Nik Twerdochlib
Software Developer

BOMGAR | The Box That’s Revolutionizing Remote Support™

One of the Fastest-Growing Technology Companies in America | Technology Fast 500™

What is Bomgar? Find out in 154 secondshttp:.
From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.com] On Behalf Of Nik Twerdochlib
Sent: Tuesday, May 21, 2013 4:52 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] [nik] XDDM Mirror Driver under Windows 8

The following stack trace is from the crash I am running into. It is in the display driver, and hardcoded breakpoints I have set in DrvEnableDriver and DrvEnablePDEV do not get hit. I am kind of thinking that the entry point of DrvEnableDriver is not getting set correctly? This is under x64.

ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY (fc)
An attempt was made to execute non-executable memory. The guilty driver
is on the stack trace (and is typically the current instruction pointer).
When possible, the guilty driver’s name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: fffff96000a03000, Virtual address for the attempted execute.
Arg2: 800000006c585221, PTE contents.
Arg3: fffff88009110170, (reserved)
Arg4: 0000000000000002, (reserved)

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

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0xFC

PROCESS_NAME: bomgar-scc-x64

CURRENT_IRQL: 0

TRAP_FRAME: fffff88009110170 – (.trap 0xfffff88009110170)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff901006f59d0 rbx=0000000000000000 rcx=0000000000030101
rdx=0000000000000010 rsi=0000000000000000 rdi=0000000000000000
rip=fffff96000a03000 rsp=fffff88009110308 rbp=fffff88009110360
r8=fffff88009110340 r9=fffff96000a03000 r10=0000000000000000
r11=fffffa8003b2a8c0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
bgdspdrv_fffff96000a03000!MIRRSURF::MIRRSURF (bgdspdrv_fffff96000a03000+0x0):
fffff96000a03000 4d5a pop r10<br>Resetting default scope<br><br>LAST_CONTROL_TRANSFER: from fffff800b21ef28a to fffff800b20c6cf0<br><br>STACK_TEXT:<br>fffff8800910f788 fffff800b21ef28a : 0000000000000000 00000000000000fc fffff8800910f8f0 fffff800b213abc8 : nt!DbgBreakPointWithStatus<br>fffff8800910f790 fffff800b21ee8de : 0000000000000003 fffff8800910f8f0 fffff800b2134550 fffff8800910fe40 : nt!KiBugCheckDebugBreak+0x12<br>fffff8800910f7f0 fffff800b20cc544 : fffff901006f59d0 0000000000000000 0000000000000000 fffff800b215a3d7 : nt!KeBugCheck2+0x79f<br>fffff8800910ff10 fffff800b225e016 : 00000000000000fc fffff96000a03000 800000006c585221 fffff88009110170 : nt!KeBugCheckEx+0x104<br>fffff8800910ff50 fffff800b2132161 : 800000006c585221 0000000000000001 fffff88009110020 fffff88009110030 : nt! ?? ::FNODOBFM::string’+0x344e2
fffff8800910ff90 fffff800b2106acb : 0000000000000008 fffff96000a03000 fffffa8003b2a8c0 fffff88009110260 : nt!MiSystemFault+0x9a7
fffff88009110030 fffff800b20c9eee : 0000000000000008 fffff90104f2fc70 0000000000000000 fffff88009110170 : nt!MmAccessFault+0x55b
fffff88009110170 fffff96000a03000 : fffff9600021c8ec 0000000000000000 0000000000000000 fffff90104456ab0 : nt!KiPageFault+0x16e
fffff88009110308 fffff9600021c8ec : 0000000000000000 0000000000000000 fffff90104456ab0 fffff88009110360 : bgdspdrv_fffff96000a03000!MIRRSURF::MIRRSURF (bgdspdrv_fffff96000a03000+0x0)
fffff88009110310 fffff9600021c57d : 0000000000000000 0000000000000000 fffff88009110430 0000000000000000 : win32k!ldevLoadDriver+0x178
fffff88009110390 fffff9600021c2d2 : fffff90100725010 0000000000000000 fffff90104456a80 fffff960002004b5 : win32k!ldevGetDriverModes+0x45
fffff880091103e0 fffff9600021d6dc : 0000000000000000 0000000000000000 fffff880091106f0 0000000000000000 : win32k!DrvBuildDevmodeList+0x10e
fffff88009110430 fffff960002176fe : fffff90100725010 fffff88009110678 fffff88000000000 fffffa8000000000 : win32k!DrvProbeAndCaptureDevmode+0x534
fffff880091105f0 fffff9600021149b : 0000000000000001 0000000000000000 0000000000000000 0000000000000000 : win32k!DrvInternalChangeDisplaySettings+0x1f2
fffff88009110880 fffff960002672f2 : fffff90100582150 fffff901000b7010 0000000000000001 05bbc46000000004 : win32k!DrvChangeDisplaySettings+0xafb
fffff88009110a50 fffff96000266dee : 0000000000000000 00000000058feae0 0000000000000000 0000000000000000 : win32k!xxxInternalUserChangeDisplaySettings+0x212
fffff88009110b10 fffff96000266d11 : 00000000058feae0 00000000058febe0 0000000040000009 0000000040000009 : win32k!xxxUserChangeDisplaySettings+0xae
fffff88009110be0 fffff800b20cb453 : fffffa8003b2a8c0 fffff88009110cc0 0000000040000009 0000000000000924 : win32k!NtUserChangeDisplaySettings+0xb1
fffff88009110c40 000007fef330327a : 000007fef3304620 cccccccccccccccc 0000000000000030 cccccccccccccccc : nt!KiSystemServiceCopyEnd+0x13
00000000058feab8 000007fef3304620 : cccccccccccccccc 0000000000000030 cccccccccccccccc cccccccc00000001 : USER32!NtUserChangeDisplaySettings+0xa
00000000058feac0 000007f74c7bffa5 : 0000000000000000 0000000000000000 0000000000000000 00000000058fecbc : USER32!ChangeDisplaySettingsExW+0x50
00000000058feb00 0000000000000000 : 0000000000000000 0000000000000000 00000000058fecbc 0000000000000000 : bomgar_scc_x64!nstv::MirrorDriver::Connect+0x2d5 [f:\source\bomgar.git\networkstreaming\tunnelvision\src\win32\mirrordriver.cpp @ 197]

STACK_COMMAND: kb

FOLLOWUP_IP:
win32k!ldevLoadDriver+178
fffff960`0021c8ec 85c0 test eax,eax

SYMBOL_STACK_INDEX: 9

SYMBOL_NAME: win32k!ldevLoadDriver+178

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: win32k

IMAGE_NAME: win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 51637e38

BUCKET_ID_FUNC_OFFSET: 178

FAILURE_BUCKET_ID: 0xFC_win32k!ldevLoadDriver

BUCKET_ID: 0xFC_win32k!ldevLoadDriver

Followup: MachineOwner
---------

Am I way off base here in thinking that fffff96000a03000 is being treated as the entry point address? Reviewing the generated map file I don’t see an entry for DrvEnableDriver so that makes me think it is correct, but I am also noticing some additional settings that appear to be merging sections?

_TEXT=.text;_PAGE=PAGE

This project has been around since NT2K and I converted it with nmake2msbuild. I am also wondering if I have “inherited” some configuration that was needed back then and is just not compatible now. I need to probably step back and compare this project to the DDK7 mirror example. Possible take another stab at getting that to load.

Nik Twerdochlib
Software Developer

+1.601.607.8309 O
+1.866.522.8678 F

BOMGAR | The Box That’s Revolutionizing Remote Support™

One of the Fastest-Growing Technology Companies in America | Technology Fast 500™

What is Bomgar? Find out in 154 secondshttp:.
From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.com] On Behalf Of Nik Twerdochlib
Sent: Monday, May 20, 2013 10:38 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] [nik] XDDM Mirror Driver under Windows 8

I am currently changing our mirror driver, which runs on systems up and until Windows 7, to run under Windows 8. To accomplish this I am changing the driver to conform to a Remote Display Driver as defined by Microsoft. This states that GCAPS2_REMOTEDRIVER be set in flGraphicsCaps. This is not defined in the Windows 7 DDK, but is in the Windows 8 DDK so I have made the assumption that the driver would need to be compiled under the Win 8 DDK?

Running a driver compiled under the 8 DDK I get a crash occurring somewhere in/near driver load that I can’t seem to trap in windbg. This driver does store some pointers to some functions like MajorFunction[IRP_MG_PNP] which to me are suspect. Are there any tricks to setting breakpoints in the supporting DLL? I am not sure if the dll is mapped into user space or kernel space by the GDI?

If I run a same driver code compiled under the 7 DDK, it will load and function when pointing to the primary display. Once I attempt to attach to a second display I appear to get screen updates from the primary display still but cursor updates for the second display. This has puzzled me, and if anyone has any insight here it would be greatly appreciated. Also, when the code recreates its surface for the second display, I have verified that the DevInfo.dmPosition is indeed correct.

I know I am trying to fix a suspension bridge here with dental floss; being that XDDM is really at its end with Windows 8. However I am hoping that getting it to conform to a Remote Display driver can buy me some time to determine which technology to replace it with.

The last question I have here is in reference to the definition of a Remote Display Driver, where it states that only a select few of the DrvXXX functions can be defined. Do they all need to be provided by the driver? or no more than what’s listed and it is up to the implementer to choose which?

Thanks,

Nik Twerdochlib
Software Developer

BOMGAR | The Box That’s Revolutionizing Remote Support™

One of the Fastest-Growing Technology Companies in America | Technology Fast 500™

What is Bomgar? Find out in 154 secondshttp:.


NTDEV is sponsored by OSR

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

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

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</http:></mailto:xxxxx></http:></mailto:xxxxx></http:></http:>

Might be possible. Can you post your sources file and if you have one, makefile.inc ?

d

Bent from my phone


From: Nik Twerdochlibmailto:xxxxx
Sent: ?5/?22/?2013 6:53 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE: [ntdev] [nik] XDDM Mirror Driver under Windows 8

So is it possible that nmake2msbuild conversion utility add the /NOENTRY to the linker command line? I see that this is set on two different projects that I have converted and removing it allows the intended entry point to be set.

Nik Twerdochlib
Software Developer

BOMGAR | The Box That’s Revolutionizing Remote Support?

One of the Fastest-Growing Technology Companies in America | Technology Fast 500?

What is Bomgar? Find out in 154 secondshttp:.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Nik Twerdochlib
Sent: Wednesday, May 22, 2013 9:39 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] [nik] XDDM Mirror Driver under Windows 8

Reviewing dumpbin output for a display driver compiled under VS2012 vs one compiled under DDK 7, I am finding that the DDK 8 driver does not have an entry point listed in the optional headers? I have confirmed that the project as one set. Is there something else I need to set?

Nik Twerdochlib
Software Developer

BOMGAR | The Box That’s Revolutionizing Remote Support?

One of the Fastest-Growing Technology Companies in America | Technology Fast 500?

What is Bomgar? Find out in 154 secondshttp:.
From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.com] On Behalf Of Nik Twerdochlib
Sent: Tuesday, May 21, 2013 4:52 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] [nik] XDDM Mirror Driver under Windows 8

The following stack trace is from the crash I am running into. It is in the display driver, and hardcoded breakpoints I have set in DrvEnableDriver and DrvEnablePDEV do not get hit. I am kind of thinking that the entry point of DrvEnableDriver is not getting set correctly? This is under x64.

ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY (fc)
An attempt was made to execute non-executable memory. The guilty driver
is on the stack trace (and is typically the current instruction pointer).
When possible, the guilty driver’s name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: fffff96000a03000, Virtual address for the attempted execute.
Arg2: 800000006c585221, PTE contents.
Arg3: fffff88009110170, (reserved)
Arg4: 0000000000000002, (reserved)

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

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0xFC

PROCESS_NAME: bomgar-scc-x64

CURRENT_IRQL: 0

TRAP_FRAME: fffff88009110170 – (.trap 0xfffff88009110170)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff901006f59d0 rbx=0000000000000000 rcx=0000000000030101
rdx=0000000000000010 rsi=0000000000000000 rdi=0000000000000000
rip=fffff96000a03000 rsp=fffff88009110308 rbp=fffff88009110360
r8=fffff88009110340 r9=fffff96000a03000 r10=0000000000000000
r11=fffffa8003b2a8c0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
bgdspdrv_fffff96000a03000!MIRRSURF::MIRRSURF (bgdspdrv_fffff96000a03000+0x0):
fffff96000a03000 4d5a pop r10<br>Resetting default scope<br><br>LAST_CONTROL_TRANSFER: from fffff800b21ef28a to fffff800b20c6cf0<br><br>STACK_TEXT:<br>fffff8800910f788 fffff800b21ef28a : 0000000000000000 00000000000000fc fffff8800910f8f0 fffff800b213abc8 : nt!DbgBreakPointWithStatus<br>fffff8800910f790 fffff800b21ee8de : 0000000000000003 fffff8800910f8f0 fffff800b2134550 fffff8800910fe40 : nt!KiBugCheckDebugBreak+0x12<br>fffff8800910f7f0 fffff800b20cc544 : fffff901006f59d0 0000000000000000 0000000000000000 fffff800b215a3d7 : nt!KeBugCheck2+0x79f<br>fffff8800910ff10 fffff800b225e016 : 00000000000000fc fffff96000a03000 800000006c585221 fffff88009110170 : nt!KeBugCheckEx+0x104<br>fffff8800910ff50 fffff800b2132161 : 800000006c585221 0000000000000001 fffff88009110020 fffff88009110030 : nt! ?? ::FNODOBFM::string’+0x344e2
fffff8800910ff90 fffff800b2106acb : 0000000000000008 fffff96000a03000 fffffa8003b2a8c0 fffff88009110260 : nt!MiSystemFault+0x9a7
fffff88009110030 fffff800b20c9eee : 0000000000000008 fffff90104f2fc70 0000000000000000 fffff88009110170 : nt!MmAccessFault+0x55b
fffff88009110170 fffff96000a03000 : fffff9600021c8ec 0000000000000000 0000000000000000 fffff90104456ab0 : nt!KiPageFault+0x16e
fffff88009110308 fffff9600021c8ec : 0000000000000000 0000000000000000 fffff90104456ab0 fffff88009110360 : bgdspdrv_fffff96000a03000!MIRRSURF::MIRRSURF (bgdspdrv_fffff96000a03000+0x0)
fffff88009110310 fffff9600021c57d : 0000000000000000 0000000000000000 fffff88009110430 0000000000000000 : win32k!ldevLoadDriver+0x178
fffff88009110390 fffff9600021c2d2 : fffff90100725010 0000000000000000 fffff90104456a80 fffff960002004b5 : win32k!ldevGetDriverModes+0x45
fffff880091103e0 fffff9600021d6dc : 0000000000000000 0000000000000000 fffff880091106f0 0000000000000000 : win32k!DrvBuildDevmodeList+0x10e
fffff88009110430 fffff960002176fe : fffff90100725010 fffff88009110678 fffff88000000000 fffffa8000000000 : win32k!DrvProbeAndCaptureDevmode+0x534
fffff880091105f0 fffff9600021149b : 0000000000000001 0000000000000000 0000000000000000 0000000000000000 : win32k!DrvInternalChangeDisplaySettings+0x1f2
fffff88009110880 fffff960002672f2 : fffff90100582150 fffff901000b7010 0000000000000001 05bbc46000000004 : win32k!DrvChangeDisplaySettings+0xafb
fffff88009110a50 fffff96000266dee : 0000000000000000 00000000058feae0 0000000000000000 0000000000000000 : win32k!xxxInternalUserChangeDisplaySettings+0x212
fffff88009110b10 fffff96000266d11 : 00000000058feae0 00000000058febe0 0000000040000009 0000000040000009 : win32k!xxxUserChangeDisplaySettings+0xae
fffff88009110be0 fffff800b20cb453 : fffffa8003b2a8c0 fffff88009110cc0 0000000040000009 0000000000000924 : win32k!NtUserChangeDisplaySettings+0xb1
fffff88009110c40 000007fef330327a : 000007fef3304620 cccccccccccccccc 0000000000000030 cccccccccccccccc : nt!KiSystemServiceCopyEnd+0x13
00000000058feab8 000007fef3304620 : cccccccccccccccc 0000000000000030 cccccccccccccccc cccccccc00000001 : USER32!NtUserChangeDisplaySettings+0xa
00000000058feac0 000007f74c7bffa5 : 0000000000000000 0000000000000000 0000000000000000 00000000058fecbc : USER32!ChangeDisplaySettingsExW+0x50
00000000058feb00 0000000000000000 : 0000000000000000 0000000000000000 00000000058fecbc 0000000000000000 : bomgar_scc_x64!nstv::MirrorDriver::Connect+0x2d5 [f:\source\bomgar.git\networkstreaming\tunnelvision\src\win32\mirrordriver.cpp @ 197]

STACK_COMMAND: kb

FOLLOWUP_IP:
win32k!ldevLoadDriver+178
fffff960`0021c8ec 85c0 test eax,eax

SYMBOL_STACK_INDEX: 9

SYMBOL_NAME: win32k!ldevLoadDriver+178

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: win32k

IMAGE_NAME: win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 51637e38

BUCKET_ID_FUNC_OFFSET: 178

FAILURE_BUCKET_ID: 0xFC_win32k!ldevLoadDriver

BUCKET_ID: 0xFC_win32k!ldevLoadDriver

Followup: MachineOwner
---------

Am I way off base here in thinking that fffff96000a03000 is being treated as the entry point address? Reviewing the generated map file I don?t see an entry for DrvEnableDriver so that makes me think it is correct, but I am also noticing some additional settings that appear to be merging sections?

_TEXT=.text;_PAGE=PAGE

This project has been around since NT2K and I converted it with nmake2msbuild. I am also wondering if I have ?inherited? some configuration that was needed back then and is just not compatible now. I need to probably step back and compare this project to the DDK7 mirror example. Possible take another stab at getting that to load.

Nik Twerdochlib
Software Developer

+1.601.607.8309 O
+1.866.522.8678 F

BOMGAR | The Box That’s Revolutionizing Remote Support?

One of the Fastest-Growing Technology Companies in America | Technology Fast 500?

What is Bomgar? Find out in 154 secondshttp:.
From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.com] On Behalf Of Nik Twerdochlib
Sent: Monday, May 20, 2013 10:38 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] [nik] XDDM Mirror Driver under Windows 8

I am currently changing our mirror driver, which runs on systems up and until Windows 7, to run under Windows 8. To accomplish this I am changing the driver to conform to a Remote Display Driver as defined by Microsoft. This states that GCAPS2_REMOTEDRIVER be set in flGraphicsCaps. This is not defined in the Windows 7 DDK, but is in the Windows 8 DDK so I have made the assumption that the driver would need to be compiled under the Win 8 DDK?

Running a driver compiled under the 8 DDK I get a crash occurring somewhere in/near driver load that I can’t seem to trap in windbg. This driver does store some pointers to some functions like MajorFunction[IRP_MG_PNP] which to me are suspect. Are there any tricks to setting breakpoints in the supporting DLL? I am not sure if the dll is mapped into user space or kernel space by the GDI?

If I run a same driver code compiled under the 7 DDK, it will load and function when pointing to the primary display. Once I attempt to attach to a second display I appear to get screen updates from the primary display still but cursor updates for the second display. This has puzzled me, and if anyone has any insight here it would be greatly appreciated. Also, when the code recreates its surface for the second display, I have verified that the DevInfo.dmPosition is indeed correct.

I know I am trying to fix a suspension bridge here with dental floss; being that XDDM is really at its end with Windows 8. However I am hoping that getting it to conform to a Remote Display driver can buy me some time to determine which technology to replace it with.

The last question I have here is in reference to the definition of a Remote Display Driver, where it states that only a select few of the DrvXXX functions can be defined. Do they all need to be provided by the driver? or no more than what?s listed and it is up to the implementer to choose which?

Thanks,

Nik Twerdochlib
Software Developer

BOMGAR | The Box That’s Revolutionizing Remote Support?

One of the Fastest-Growing Technology Companies in America | Technology Fast 500?

What is Bomgar? Find out in 154 secondshttp:.


NTDEV is sponsored by OSR

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

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

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

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</http:></mailto:xxxxx></http:></mailto:xxxxx></http:></http:></mailto:xxxxx></mailto:xxxxx>

Did you ever resolve the second part of your question/problem:
"
If I run a same driver code compiled under the 7 DDK, it will load and function when pointing to the primary display. Once I attempt to attach to a second display I appear to get screen updates from the primary display still but cursor updates for the second display. This has puzzled me, and if anyone has any insight here it would be greatly appreciated. Also, when the code recreates its surface for the second display, I have verified that the DevInfo.dmPosition is indeed correct.
"
Thanks
Robert