Display Mirror Driver problems

Hi,

I am developing a display mirror drive, following is a description of
several issues I have encountered, any help will be appreciated.

Issue One:
INTRODUCTION: I am tying to map kernel memory to user memory in a mirror
display driver based upon the sample given in the DDK, to achieve the
mapping I have created an external DLL ( Here on this DLL will be referred
as DispCmn.DLL ) that encapsulate all of the memory management functions (
e.g. SHM_Alloc and SHM_Dealloc ), I am using EngLoadImage in combination
with EngFindImageProcAddress to access the methods just described
THE PROBLEM: EngLoadImage returns NULL although the binary DLL file is
actually being accessed by the kernel ( this was verified using sysinternals
FileMon ), Why is that happening? the DLL ( DispCmn.DLL ) is being linked
with wdm.lib and is dependent on NTOSKRNL.EXE and KERNEL32.DLL, may this
dependency impose any problems? does EngLoadImage restricts certain DLLs
from being loaded?

Issue Two:
The Mirror sample provided with the DDK include some default hooking ( e.g.
INDEX_DrvEnableSurface and INDEX_DrvDisableSurface ) Does this hooking are
mandatory? Is it OK to disable those hooking ( for the time being )?
Is some hooking are mandatory how can one know what are and what are not?

Issue Three:
The development cycle of a mirror driver is not of the shortest: one should
reboot the system each time the mirror driver is to be updated, I wonder...
Is there a way of unloading the mirror driver without rebooting the system?
this will save me a lot of the development time.

ThanX
Nadav.
See a great COM Profiling tool I have developed at
http://www.ddevel.com/DrCOM.asp

Hi, Nadav

Issue One:
First of all, your external DLL have reference to
user-mode DLL (namely, kernel32.dll). Such a DLL cant be loaded
at all. You have to check "Ignore standard libraries" in you project
and remove link references to anything except for win32k.lib and
possibly int64.lib, libcntpr.lib.
The memory mapping and the other tasks that require calls to
ntoskrnl are better performed by miniport driver.
Miniport is not restricted in what it can do. Add 2 IOCTLs to
it and call it from the display part.

Issue Two:
Yes, this hooking is mandatory. If you don't install this,
the GDI will not be able to create the screen surface on your device.
So your driver will be unloaded as being useless.
Mandatory hooks are enumerated in Windows DDK.

Issue Three:
The mirror driver, as any other display driver, is unloaded
when the video mode settings change and it is no longer
required to be loaded.
It is about Attach.ToDesktop registry value
(CurrentControlSet\HardwareProfiles subtree, not CurrentControlSet\Services
one).


------------------------
Unfortunately you didn't left your real e-mail address.
So, if you want to talk more about mirror drivers, feel free to
contact me.

--------------------
Lev Kazarkin
Mirror drivers. Consulting and custom development.



"Nadav" <Not@today.com> wrote in message
news:eEGrUTT9DHA.3404@TK2MSFTNGP09.phx.gbl...
> Hi,
>
> I am developing a display mirror drive, following is a description of
> several issues I have encountered, any help will be appreciated.
>
> Issue One:
> INTRODUCTION: I am tying to map kernel memory to user memory in a mirror
> display driver based upon the sample given in the DDK, to achieve the
> mapping I have created an external DLL ( Here on this DLL will be referred
> as DispCmn.DLL ) that encapsulate all of the memory management functions (
> e.g. SHM_Alloc and SHM_Dealloc ), I am using EngLoadImage in combination
> with EngFindImageProcAddress to access the methods just described
> THE PROBLEM: EngLoadImage returns NULL although the binary DLL file is
> actually being accessed by the kernel ( this was verified using
sysinternals
> FileMon ), Why is that happening? the DLL ( DispCmn.DLL ) is being linked
> with wdm.lib and is dependent on NTOSKRNL.EXE and KERNEL32.DLL, may this
> dependency impose any problems? does EngLoadImage restricts certain DLLs
> from being loaded?
>
> Issue Two:
> The Mirror sample provided with the DDK include some default hooking (
e.g.
> INDEX_DrvEnableSurface and INDEX_DrvDisableSurface ) Does this hooking are
> mandatory? Is it OK to disable those hooking ( for the time being )?
> Is some hooking are mandatory how can one know what are and what are not?
>
> Issue Three:
> The development cycle of a mirror driver is not of the shortest: one
should
> reboot the system each time the mirror driver is to be updated, I
wonder...
> Is there a way of unloading the mirror driver without rebooting the
system?
> this will save me a lot of the development time.
>
> ThanX
> Nadav.
> See a great COM Profiling tool I have developed at
> http://www.ddevel.com/DrCOM.asp
>

ThanX For your response, It is very helpful.

Concerning Issue Three, SO... Please fix me if I am wrong, Lets take the
following scenario as an example of what I have understand of your response:
1. A mirror Driver is loaded
2. I have set the 'Attach.ToDesktop' registry value to Zero
3. I am changing the video mode ( changing the resolution of the screen )
4. The mirror driver will be unloaded and the Driver .DLL would be able to
be deleted/changed
Did I get It right?


"DemoForge.com" <mirrdrv@demoforge.com> wrote in message
news:OKt0ilU9DHA.3648@TK2MSFTNGP11.phx.gbl...
>
> Hi, Nadav
>
> Issue One:
> First of all, your external DLL have reference to
> user-mode DLL (namely, kernel32.dll). Such a DLL cant be loaded
> at all. You have to check "Ignore standard libraries" in you project
> and remove link references to anything except for win32k.lib and
> possibly int64.lib, libcntpr.lib.
> The memory mapping and the other tasks that require calls to
> ntoskrnl are better performed by miniport driver.
> Miniport is not restricted in what it can do. Add 2 IOCTLs to
> it and call it from the display part.
>
> Issue Two:
> Yes, this hooking is mandatory. If you don't install this,
> the GDI will not be able to create the screen surface on your device.
> So your driver will be unloaded as being useless.
> Mandatory hooks are enumerated in Windows DDK.
>
> Issue Three:
> The mirror driver, as any other display driver, is unloaded
> when the video mode settings change and it is no longer
> required to be loaded.
> It is about Attach.ToDesktop registry value
> (CurrentControlSet\HardwareProfiles subtree, not
CurrentControlSet\Services
> one).
>
>
> ------------------------
> Unfortunately you didn't left your real e-mail address.
> So, if you want to talk more about mirror drivers, feel free to
> contact me.
>
> --------------------
> Lev Kazarkin
> Mirror drivers. Consulting and custom development.
>
>
>
> "Nadav" <Not@today.com> wrote in message
> news:eEGrUTT9DHA.3404@TK2MSFTNGP09.phx.gbl...
> > Hi,
> >
> > I am developing a display mirror drive, following is a description of
> > several issues I have encountered, any help will be appreciated.
> >
> > Issue One:
> > INTRODUCTION: I am tying to map kernel memory to user memory in a mirror
> > display driver based upon the sample given in the DDK, to achieve the
> > mapping I have created an external DLL ( Here on this DLL will be
referred
> > as DispCmn.DLL ) that encapsulate all of the memory management functions
(
> > e.g. SHM_Alloc and SHM_Dealloc ), I am using EngLoadImage in combination
> > with EngFindImageProcAddress to access the methods just described
> > THE PROBLEM: EngLoadImage returns NULL although the binary DLL file is
> > actually being accessed by the kernel ( this was verified using
> sysinternals
> > FileMon ), Why is that happening? the DLL ( DispCmn.DLL ) is being
linked
> > with wdm.lib and is dependent on NTOSKRNL.EXE and KERNEL32.DLL, may this
> > dependency impose any problems? does EngLoadImage restricts certain DLLs
> > from being loaded?
> >
> > Issue Two:
> > The Mirror sample provided with the DDK include some default hooking (
> e.g.
> > INDEX_DrvEnableSurface and INDEX_DrvDisableSurface ) Does this hooking
are
> > mandatory? Is it OK to disable those hooking ( for the time being )?
> > Is some hooking are mandatory how can one know what are and what are
not?
> >
> > Issue Three:
> > The development cycle of a mirror driver is not of the shortest: one
> should
> > reboot the system each time the mirror driver is to be updated, I
> wonder...
> > Is there a way of unloading the mirror driver without rebooting the
> system?
> > this will save me a lot of the development time.
> >
> > ThanX
> > Nadav.
> > See a great COM Profiling tool I have developed at
> > http://www.ddevel.com/DrCOM.asp
> >
>
>

> Concerning Issue Three, SO... Please fix me if I am wrong, Lets take the
> following scenario as an example of what I have understand of your response:
> 1. A mirror Driver is loaded
> 2. I have set the 'Attach.ToDesktop' registry value to Zero
> 3. I am changing the video mode ( changing the resolution of the screen )
> 4. The mirror driver will be unloaded and the Driver .DLL would be able to
> be deleted/changed
> Did I get It right?

Yes. You have to set the Attach.ToDesktop to zero, and then change the
display settings for the Mirror driver, using ChangeDisplaySettingsEx.

Note: This is not the standard way to detach ordinary display drivers.
Normally, you set DM_POSITION, and then specify the width and height
as 0, and just do a call to ChangeDisplaySettingsEx. Unfortunately,
there is a bug in windows which prevents this working for mirror
drivers.

Cheers,
Otto