Mirror Display Driver - Log off system crush

NTDEV
1

Hi.
I’m developing Mirror Display Driver and everything works norm, except one problem.
In windows Vista I have system crush (BSOD) when I do following steps -> start windows -> log into account -> Log off -> at the end of log off I get blue screen of death.
And in Windows Xp I get not the same but similar situation when I do following steps -> start windows -> Log into account -> switch into another account -> log off -> blue screen.
The crush dump in Vista is
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SESSION_HAS_VALID_POOL_ON_EXIT (ab)
Caused by a session driver not freeing its pool allocations prior to a
session unload. This indicates a bug in win32k.sys, atmfd.dll,
rdpdd.dll or a video driver.
Arguments:
Arg1: 00000001, session ID
Arg2: 00000028, number of paged pool bytes that are leaking
Arg3: 00000000, number of nonpaged pool bytes that are leaking
Arg4: 00000001, total number of paged and nonpaged allocations that are leaking.
nonpaged allocations are in the upper half of this word,
paged allocations are in the lower half of this word.

Debugging Details:

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xAB

PROCESS_NAME: @¦?

LAST_CONTROL_TRANSFER: from 819e59ea to 818d85c9

STACK_TEXT:
88dcbbac 819e59ea 000000ab 00000001 00000028 nt!ObReferenceObjectByHandle+0x39
88dcbbe8 81ac389e 836a1d78 00000001 83542ac0 nt!_NULL_IMPORT_DESCRIPTOR (nt+0x1e59ea)
88dcbc38 819e4eaf 83542c90 81932900 88dcbc74 nt!_NULL_IMPORT_DESCRIPTOR (nt+0x2c389e)
88dcbc48 81819c1a 83542ac0 83542ac0 836a1d78 nt!_NULL_IMPORT_DESCRIPTOR (nt+0x1e4eaf)
88dcbc74 81a1bcd4 83542ac0 88dc079c 83535498 nt!IoVolumeDeviceToDosName+0x18c
88dcbcdc 81a1b58d 00000000 836a1d78 836a1d01 nt!_NULL_IMPORT_DESCRIPTOR (nt+0x21bcd4)
88dcbcf4 818b1410 83535498 88dcbd20 88dcbd2c nt!_NULL_IMPORT_DESCRIPTOR (nt+0x21b58d)
88dcbd4c 8188ca15 00000001 00000000 88dcbd64 nt!IopInvalidateRelationsInList+0x4
88dcbd64 77b90f34 badb0d00 0031f890 00000000 nt!FsRtlNotifyCleanup+0xf9
WARNING: Frame IP not in any known module. Following frames may be wrong.
88dcbd68 badb0d00 0031f890 00000000 00000000 0x77b90f34
88dcbd6c 0031f890 00000000 00000000 00000000 0xbadb0d00
88dcbd70 00000000 00000000 00000000 00000000 0x31f890

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!IoVolumeDeviceToDosName+18c
81819c1a ?? ???

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: nt!IoVolumeDeviceToDosName+18c

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlpa.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4549ae00

FAILURE_BUCKET_ID: 0xAB_nt!IoVolumeDeviceToDosName+18c

BUCKET_ID: 0xAB_nt!IoVolumeDeviceToDosName+18c

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

As I have understood this crush occurs not in my driver but it not occurs without my mirror driver installed.
Could someone can describe something about this situation?

2

If the same bugcheck code occurs in both Vista and in XP, it indicates that the problem is in the video miniport driver, not the display driver. Display drivers in Vista are loaded into user space and not kernel space, thus a crash in a user-mode display driver couldn’t bring the system down in a stop error.

On the other hand, XP will load the display driver once per session (this is why you are discouraged from using global variables in display drivers in XP). Thus if your video miniport driver has been written under the assumption that there will be only one instance of the display driver loaded at any given time, your minport driver probably will crash when the display driver sends an unload request.

Vista, on the other hand, loads the display driver once per DirectX context. Windows Aero uses one such context when it’s on, and it’s possible that during the logoff process a second DirectX context is being created. Under such a circumstance, you may get a crash for the same reason you get a crash in XP.

In any case, I’d recommend you check your video minport driver for multiple display driver cases and see what you find.

Help yourself to FREE treats served up daily at the Messenger Caf?. Stop by today.
http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline

3

I don’t know if it’s the same bugcheck, because in Xp the debugger can’t find the correct symbols.
Strange but only for this crush it can’t find them. The paths appears to be correct.
In Xp I get
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SESSION_HAS_VALID_VIEWS_ON_EXIT (ba)
Caused by a session driver not unmapping its mapped views prior to a
session unload. This indicates a bug in win32k.sys, atmfd.dll,
rdpdd.dll or a video driver.
Arguments:
Arg1: 00000001, session ID
Arg2: 00000001, number of mapped views that are leaking
Arg3: e1a1be28, address of this session’s mapped views table
Arg4: 0000001f, size of this session’s mapped views table.

Debugging Details:

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: mssmbios!_SMBIOS_DATA_OBJECT ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: mssmbios!_SMBIOS_DATA_OBJECT ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: mssmbios!_SMBIOS_DATA_OBJECT ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: mssmbios!_SMBIOS_DATA_OBJECT ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: mssmbios!_SMBIOS_DATA_OBJECT ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: mssmbios!_SMBIOS_DATA_OBJECT ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: mssmbios!_SMBIOS_DATA_OBJECT ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: mssmbios!_SMBIOS_DATA_OBJECT ***
*** ***
*************************************************************************

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xBA

LAST_CONTROL_TRANSFER: from 00000000 to 8053a54e

STACK_TEXT:
aa294b88 00000000 00000001 00000001 e1a1be28 nt!KeBugCheck2+0x704

STACK_COMMAND: kb

SYMBOL_NAME: ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

FAILURE_BUCKET_ID: 0xBA_ANALYSIS_INCONCLUSIVE

BUCKET_ID: 0xBA_ANALYSIS_INCONCLUSIVE

Followup: MachineOwner

Maybe this bug occurs in miniport driver, but I haven’t modified code inside this driver.
My miniport driver have the same code as in the sample.

4

Jason Sanchez wrote:

If the same bugcheck code occurs in both Vista and in XP, it indicates
that the problem is in the video miniport driver, not the display
driver. Display drivers in Vista are loaded into user space and not
kernel space, thus a crash in a user-mode display driver couldn’t
bring the system down in a stop error.

WDDM drivers in Vista are loaded into user space. He’s writing a mirror
driver, which means it is XPDM and therefore still in kernel space.

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

5

xxxxx@gmail.com wrote:

I’m developing Mirror Display Driver and everything works norm, except one problem.
In windows Vista I have system crush (BSOD) when I do following steps -> start windows -> log into account -> Log off -> at the end of log off I get blue screen of death.
And in Windows Xp I get not the same but similar situation when I do following steps -> start windows -> Log into account -> switch into another account -> log off -> blue screen.
The crush dump in Vista is
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SESSION_HAS_VALID_POOL_ON_EXIT (ab)
Caused by a session driver not freeing its pool allocations prior to a
session unload. This indicates a bug in win32k.sys, atmfd.dll,
rdpdd.dll or a video driver.
Arguments:
Arg1: 00000001, session ID
Arg2: 00000028, number of paged pool bytes that are leaking
Arg3: 00000000, number of nonpaged pool bytes that are leaking
Arg4: 00000001, total number of paged and nonpaged allocations that are leaking.
nonpaged allocations are in the upper half of this word,
paged allocations are in the lower half of this word.
…

As I have understood this crush occurs not in my driver but it not occurs without my mirror driver installed.
Could someone can describe something about this situation?

How could the analysis possibly be any more clear? You have allocated
one block of 40 bytes from paged pool, and did not free it before you
unloaded. 40 bytes happens to be the size of a BITMAPINFOHEADER.

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

6

xxxxx@gmail.com wrote:

I don’t know if it’s the same bugcheck, because in Xp the debugger can’t find the correct symbols.
Strange but only for this crush it can’t find them. The paths appears to be correct.
In Xp I get
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SESSION_HAS_VALID_VIEWS_ON_EXIT (ba)
Caused by a session driver not unmapping its mapped views prior to a
session unload. This indicates a bug in win32k.sys, atmfd.dll,
rdpdd.dll or a video driver.
Arguments:
Arg1: 00000001, session ID
Arg2: 00000001, number of mapped views that are leaking
Arg3: e1a1be28, address of this session’s mapped views table
Arg4: 0000001f, size of this session’s mapped views table.

Again, it’s hard for me to see how this could be any more helpful. You
didn’t close a memory-mapped file view before the driver unloaded.
Since we know your driver uses a memory mapped file, this seems
absolutely clear.

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

7

You’re right again. I think it’s pretty obvious, though, that the cause is related to multiple loading of the display driver, don’t you?

–Jason Sanchez

WDDM drivers in Vista are loaded into user space. He’s writing a mirror> driver, which means it is XPDM and therefore still in kernel space.> > – > Tim Roberts, xxxxx@probo.com> Providenza & Boekelheide, Inc.> > > —> 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

Climb to the top of the charts!? Play Star Shuffle:? the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct

8

> Again, it’s hard for me to see how this could be any more helpful. You> didn’t close a memory-mapped file view before the driver unloaded. > Since we know your driver uses a memory mapped file, this seems> absolutely clear.Wow, I’m an idiot too. I should have taken a look at the bug check code myself before I went and tried to give an answer to this guy. I’m glad that I subscribed to this list. It looks like I’m learning quite a bit just by trying to be helpful.

Also, I wanted to know if standard Vista display drivers (not mirror drivers) are allowed to use the old Win2k driver model in the same way mirror drivers can. I don’t think it’s the case, but you’ve proven me wrong twice already.

–Jason Sanchez

Help yourself to FREE treats served up daily at the Messenger Caf?. Stop by today.
http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline

9

Tim, you’re right about that I didn’t close a memory-mapped file.
I don’t get error in Win Xp (In Vista I still get same error) if do unmap in DrvDisableSurface, but It makes a new problem.
If change screen resolution then first will call DrvEnableSurface and then DrvDisableSurface, so memory will be unmapped that’s the problem. I was unmapping in DrvEnableSurface function before, but this occurs error on logoff (because it doesn’t unmap in DrvDisableSurface).
Could anyone can say something about this situation?

10

I think your memory-mapping approach is problematic, here, and Tim correct me if I’m wrong, but it’s rather dangerous to use memory mappings in the way you are using them. First of all, windows doesn’t guarentee that two memory-mapped views of the same file will be synchronized, and it’s just luck that they happen to synch up at all.

Second of all, if you log in a user and then switch to another user, you have *two* copies of your display driver loaded in memory, not just one. Is your system designed to handle the case when there are two drivers loaded this way? It certainly doesn’t appear to be the case.

Have you conisdered using the escape technique I described earlier? I think it will probably avoid all of the problems you’re experiencing, but it really depends on what exactly you are using this mirror driver for.

–Jason Sanchez> Date: Tue, 30 Oct 2007 14:40:45 -0500> From: xxxxx@gmail.com> To: xxxxx@lists.osr.com> Subject: RE:[ntdev] Mirror Display Driver - Log off system crush> > Tim, you’re right about that I didn’t close a memory-mapped file.> I don’t get error in Win Xp (In Vista I still get same error) if do unmap in DrvDisableSurface, but It makes a new problem.> If change screen resolution then first will call DrvEnableSurface and then DrvDisableSurface, so memory will be unmapped that’s the problem. I was unmapping in DrvEnableSurface function before, but this occurs error on logoff (because it doesn’t unmap in DrvDisableSurface).> Could anyone can say something about this situation?> > > —> 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

Help yourself to FREE treats served up daily at the Messenger Caf?. Stop by today.
http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline

11

Jason Sanchez wrote:

I think your memory-mapping approach is problematic, here, and Tim
correct me if I’m wrong, but it’s rather dangerous to use memory
mappings in the way you are using them. First of all, windows doesn’t
guarentee that two memory-mapped views of the same file will be
synchronized, and it’s just luck that they happen to synch up at all.

That’s the second time I’ve read that sentence this week, and I’m not
sure where it comes from. Multiple views of a memory-mapped file will
refer to the same pages of physical memory. I don’t believe there is
any way for them not to be synchronized. Indeed, memory-mapped files
are one of the leading methods of interprocess communication, and they
wouldn’t be much good if they weren’t really sharing a single piece of
memory.

Second of all, if you log in a user and then switch to another user,
you have *two* copies of your display driver loaded in memory, not
just one. Is your system designed to handle the case when there are
two drivers loaded this way? It certainly doesn’t appear to be the case.

THIS much is quite true.

Have you conisdered using the escape technique I described earlier? I
think it will probably avoid all of the problems you’re experiencing,
but it really depends on what exactly you are using this mirror driver
for.

We’ve been through several different architectures on this project. :wink:
As I recall, he is essentially writing a VNC, where he needs to send the
dirty rectangles across a network. He’s maintaining his frame buffer in
a memory-mapped file, with a list of dirty rectangles that the user-mode
app monitors.

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

12

xxxxx@gmail.com wrote:

Tim, you’re right about that I didn’t close a memory-mapped file.
I don’t get error in Win Xp (In Vista I still get same error) if do unmap in DrvDisableSurface, but It makes a new problem.
If change screen resolution then first will call DrvEnableSurface and then DrvDisableSurface, so memory will be unmapped that’s the problem. I was unmapping in DrvEnableSurface function before, but this occurs error on logoff (because it doesn’t unmap in DrvDisableSurface).
Could anyone can say something about this situation?

Are you using a global variable? Each surface will need its own map.
With fast user switching, or with Terminal Services, you will have
multiple instances of your mirror driver, each with its own surface,
each of which needs its own mapping. You need to close a particular
surface’s mapping in DrvDisableSurface, and close them all when your
driver shuts down, in DrvDisableDriver or DrvDisablePDEV.

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

13

Jason Sanchez wrote:

Also, I wanted to know if standard Vista display drivers (not mirror
drivers) are allowed to use the old Win2k driver model in the same way
mirror drivers can. I don’t think it’s the case, but you’ve proven me
wrong twice already.

:wink:

Old style XPDM display drivers work fine on Vista, but a machine that
has one can’t use Aero. An XPDM mirror driver also shuts down Aero.

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

14

I think you’ve got what the SDK documentation says a little jumbled, and
are perhaps misusing/confusing the terms ‘coherent’ and ‘synchronized.’

As Tim already mentioned that part about views not being coherent (what
you are calling sychronized) is not correct, with the (irrelevant in
this case, if I understand the situation correctly) exception of remote
views, which are not reconciled if they are both mapped with write
access. The other exception is that they are also not guaranteed to be
coherent if you write directly to the file handle, but I can’t think of
any reason why one would want to do that. If that’s what you meant, my
apologies, but it doesn’t seem like that.

Everything so far concerns coherency of the data, not synchronization.
As far as sychronization, the ordering of operations on the data,
Windows does not synchronize access to a memory mapped file, you have to
do that yourself. Again, perhaps that is what you meant, but it doesn’t
read like that, in my opinion.

As a hypothetical, if you were to read midway through a write, you may
not get what you want, but everyone would see the same thing. That’s
coherency. Providing a means to make sure that you don’t read until the
write completes is an example of an implementation of sychronization.

Good luck,

mm

Tim Roberts wrote:

Jason Sanchez wrote:
> I think your memory-mapping approach is problematic, here, and Tim
> correct me if I’m wrong, but it’s rather dangerous to use memory
> mappings in the way you are using them. First of all, windows doesn’t
> guarentee that two memory-mapped views of the same file will be
> synchronized, and it’s just luck that they happen to synch up at all.

That’s the second time I’ve read that sentence this week, and I’m not
sure where it comes from. Multiple views of a memory-mapped file will
refer to the same pages of physical memory. I don’t believe there is
any way for them not to be synchronized. Indeed, memory-mapped files
are one of the leading methods of interprocess communication, and they
wouldn’t be much good if they weren’t really sharing a single piece of
memory.

> Second of all, if you log in a user and then switch to another user,
> you have *two* copies of your display driver loaded in memory, not
> just one. Is your system designed to handle the case when there are
> two drivers loaded this way? It certainly doesn’t appear to be the case.

THIS much is quite true.

> Have you conisdered using the escape technique I described earlier? I
> think it will probably avoid all of the problems you’re experiencing,
> but it really depends on what exactly you are using this mirror driver
> for.

We’ve been through several different architectures on this project. :wink:
As I recall, he is essentially writing a VNC, where he needs to send the
dirty rectangles across a network. He’s maintaining his frame buffer in
a memory-mapped file, with a list of dirty rectangles that the user-mode
app monitors.

15

>Are you using a global variable?
Yes.
As I understood, I need to map more files then one?
Or it’s another way to use one mapped file?
Maybe there’s a way how enumerate surfaces and change not current surface memory from mapped to normal allocated memory (EngAllocMem) ?

16

If you need communications between user mode and driver mode, and you expect to have more than one client application for this driver, then a memory-mapped file doesn’t appear to be the best way to go. You should probably consider a shared surface–such as a DIB section–instead, so you don’t have to maintain globals.> Date: Wed, 31 Oct 2007 07:55:30 -0500> From: xxxxx@gmail.com> To: xxxxx@lists.osr.com> Subject: RE:[ntdev] Mirror Display Driver - Log off system crush> > >Are you using a global variable?> Yes.> As I understood, I need to map more files then one?> Or it’s another way to use one mapped file?> Maybe there’s a way how enumerate surfaces and change not current surface memory from mapped to normal allocated memory (EngAllocMem) ? > > —> 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

Boo!?Scare away worms, viruses and so much more! Try Windows Live OneCare!
http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews

17

>You should probably consider a shared surface–such as a DIB section–instead
But how can I use DIB section in ring 3 app?

18

I need to pass not just a surface, I also need to pass changed coordinates.

19

xxxxx@gmail.com wrote:

> Are you using a global variable?
>
Yes.
As I understood, I need to map more files then one?

Yes. With fast-user-switching, or with Terminal Services, each user has
their own display driver instance, and their own independent surface.

Or it’s another way to use one mapped file?
Maybe there’s a way how enumerate surfaces and change not current surface memory from mapped to normal allocated memory (EngAllocMem) ?

There’s really no difference between a mapped file and normal allocated
memory. It’s all memory.

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

20

>There’s really no difference between a mapped file and normal allocated memory. It’s all memory.
Yes I know. But this is not what I wanted to say. Sorry if I say something wrong.
I want to do that my driver will map only one file. I assume that it will be more better, than to have a lot of mapped files.
As much I have understood, when I switching accounts the picture that I see on display is current active surface.
When system switching or creating a new surface it calls DrvEnableSurface function. Inside this function I need to allocate memory for future surface. I want to do mapped file only map current surfaces memory. If to consider that when system creates a new surface the old must still to have own memory, I want to allocate new memory not in mapped file and assign it to old surface (ppdev->hsurfEng).
It is possible to do that?
And two more questions:
If I have for example two display on my Computer the system creates two or one surface?
And what about DIB section? How I can try to use it? It’s possible to share additional information through it?