Normal ram reported as device resource

NTDEV
1

Hi,

I have a bus driver that talks to some of our function drivers. In one case
it would be really useful to report the address of some non-paged pool (or
perhaps allocated common memory) as a device memory resource via
IRP_MN_QUERY_RESOURCES. I specifically want to do this so I can establish
communication between my bus driver, a storport based miniport and the crash
dump twin of the storport based miniport (and perhaps even the hibernate
twin). I’d use a custom resource type except storport is picky and will
only extract normal memory/port/interrupt/dma flavors of resources. To make
the crash dump twin function, it needs some values known only to the normal
device instance. Pretty much the only “parameter” passed to the crash dump
twin is the PPORT_CONFIGURATION_INFORMATION passed to FindAdapter.

It seems like normally a reported resource will be at some PCI address that
is unique from any other, and when resource arbitration happens there are no
conflicts (or rebalance happens). By definition, I want to report a resource
that has the same physical address as allocated memory (since it IS memory).

So the question comes down to: is there some combination of values I can put
in an IO_RESOURCE_DESCRIPTOR, which the PnP system will be happy with
(non-conflicting), that represents normal ram instead of the typical PCI BAR
range? Ideally, I would just like to report a virtual address value
(required resource with no alternatives) and have that value show up as a
raw or translated memory resource in the PnP start message. To assure the
virtual address doesn’t happen to conflict with a real PCI bar, I may have
to pass the physical address of the pool memory and then map it in the
miniport.

Jan

2

Jan Bottorff wrote:

I have a bus driver that talks to some of our function drivers. In one
case it would be really useful to report the address of some non-paged
pool (or perhaps allocated common memory) as a device memory resource
via IRP_MN_QUERY_RESOURCES. I specifically want to do this so I can
establish communication between my bus driver, a storport based
miniport and the crash dump twin of the storport based miniport (and
perhaps even the hibernate twin).

Why can’t you just have the function drivers send an internal ioctl to
fetch the address of this shared area?

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

3

Well… If it’s a crash dump driver (i.e. dump_MyMiniport) it doesn’t have a
driver stack (or lower device or pdo). It doesn’t even have a driver object.
DriverEntry is not called until the OS has crashed. You’re not in the normal
driver execution environment.

Jan

Jan Bottorff wrote:
>
>
>
> I have a bus driver that talks to some of our function drivers. In one
> case it would be really useful to report the address of some non-paged
> pool (or perhaps allocated common memory) as a device memory resource
> via IRP_MN_QUERY_RESOURCES. I specifically want to do this so I can
> establish communication between my bus driver, a storport based
> miniport and the crash dump twin of the storport based miniport (and
> perhaps even the hibernate twin).
>

Why can’t you just have the function drivers send an internal ioctl to
fetch the address of this shared area?

4

I don’t know what the OP is going to do with this shared memory at dump
time, but he could manage to do what he wants by having a kernel mode dll
that both his normal miniport and his dump_miniport link to. The shared
memory would be in the dll.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-303453-
xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Wednesday, October 17, 2007 3:26 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Normal ram reported as device resource

Well… If it’s a crash dump driver (i.e. dump_MyMiniport) it doesn’t
have a
driver stack (or lower device or pdo). It doesn’t even have a driver
object.
DriverEntry is not called until the OS has crashed. You’re not in the
normal
driver execution environment.

Jan

> Jan Bottorff wrote:
> >
> >
> >
> > I have a bus driver that talks to some of our function drivers. In
one
> > case it would be really useful to report the address of some non-
paged
> > pool (or perhaps allocated common memory) as a device memory
resource
> > via IRP_MN_QUERY_RESOURCES. I specifically want to do this so I can
> > establish communication between my bus driver, a storport based
> > miniport and the crash dump twin of the storport based miniport
(and
> > perhaps even the hibernate twin).
> >
>
> Why can’t you just have the function drivers send an internal ioctl
to
> fetch the address of this shared area?

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

5

A shared DLL will not work. The entire dump stack is reloaded as a new set of images, this includes any DLL you link to in the miniport (think of it as a kernel from of side by side). A good example of this is wmilib.sys, it is also reloaded in the dump stack as dump_wmilib.sys. Since the DLL is loaded side by side against itself, there are 2 copies of the DLL’s globals.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Wednesday, October 17, 2007 4:27 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Normal ram reported as device resource

I don’t know what the OP is going to do with this shared memory at dump
time, but he could manage to do what he wants by having a kernel mode dll
that both his normal miniport and his dump_miniport link to. The shared
memory would be in the dll.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-303453-
xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Wednesday, October 17, 2007 3:26 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Normal ram reported as device resource

Well… If it’s a crash dump driver (i.e. dump_MyMiniport) it doesn’t
have a
driver stack (or lower device or pdo). It doesn’t even have a driver
object.
DriverEntry is not called until the OS has crashed. You’re not in the
normal
driver execution environment.

Jan

> Jan Bottorff wrote:
> >
> >
> >
> > I have a bus driver that talks to some of our function drivers. In
one
> > case it would be really useful to report the address of some non-
paged
> > pool (or perhaps allocated common memory) as a device memory
resource
> > via IRP_MN_QUERY_RESOURCES. I specifically want to do this so I can
> > establish communication between my bus driver, a storport based
> > miniport and the crash dump twin of the storport based miniport
(and
> > perhaps even the hibernate twin).
> >
>
> Why can’t you just have the function drivers send an internal ioctl
to
> fetch the address of this shared area?

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

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

6

Good point.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, October 17, 2007 4:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Normal ram reported as device resource

A shared DLL will not work. The entire dump stack is reloaded as a new
set of images, this includes any DLL you link to in the miniport (think
of it as a kernel from of side by side). A good example of this is
wmilib.sys, it is also reloaded in the dump stack as dump_wmilib.sys.
Since the DLL is loaded side by side against itself, there are 2 copies
of the DLL’s globals.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Wednesday, October 17, 2007 4:27 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Normal ram reported as device resource

I don’t know what the OP is going to do with this shared memory at dump
time, but he could manage to do what he wants by having a kernel mode
dll
that both his normal miniport and his dump_miniport link to. The shared
memory would be in the dll.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-303453-
xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Wednesday, October 17, 2007 3:26 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Normal ram reported as device resource

Well… If it’s a crash dump driver (i.e. dump_MyMiniport) it doesn’t
have a
driver stack (or lower device or pdo). It doesn’t even have a driver
object.
DriverEntry is not called until the OS has crashed. You’re not in the
normal
driver execution environment.

Jan

> Jan Bottorff wrote:
> >
> >
> >
> > I have a bus driver that talks to some of our function drivers. In
one
> > case it would be really useful to report the address of some non-
paged
> > pool (or perhaps allocated common memory) as a device memory
resource
> > via IRP_MN_QUERY_RESOURCES. I specifically want to do this so I
can
> > establish communication between my bus driver, a storport based
> > miniport and the crash dump twin of the storport based miniport
(and
> > perhaps even the hibernate twin).
> >
>
> Why can’t you just have the function drivers send an internal ioctl
to
> fetch the address of this shared area?

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

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

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

7

Plan B: misuse ScsiPortGetUncachedExtension.

The boot adapter miniport (which is cloned as the dump adapter)
overallocates the common buffer allocated through
ScsiPortGetUncachedExtension to add a region at the front or back of the
buffer to be shared between it and the dump driver version of the
adapter miniport. The additional space is not used by the adapter
hardware.

This scheme relies on the undocumented (but all of the dump support is
undocumented) feature that when the dump driver calls
ScsiPortGetUncachedExtension it gets back the same common buffer
allocated by the boot driver’s call to ScsiPortGetUncachedExtension.

This is of course totally fragile. Some future version of dump support
may not recycle the boot device common buffer to the dump device.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Wednesday, October 17, 2007 5:18 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Normal ram reported as device resource

Good point.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, October 17, 2007 4:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Normal ram reported as device resource

A shared DLL will not work. The entire dump stack is reloaded as a new
set of images, this includes any DLL you link to in the miniport (think
of it as a kernel from of side by side). A good example of this is
wmilib.sys, it is also reloaded in the dump stack as dump_wmilib.sys.
Since the DLL is loaded side by side against itself, there are 2 copies
of the DLL’s globals.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Wednesday, October 17, 2007 4:27 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Normal ram reported as device resource

I don’t know what the OP is going to do with this shared memory at dump
time, but he could manage to do what he wants by having a kernel mode
dll
that both his normal miniport and his dump_miniport link to. The shared
memory would be in the dll.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-303453-
xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Wednesday, October 17, 2007 3:26 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Normal ram reported as device resource

Well… If it’s a crash dump driver (i.e. dump_MyMiniport) it doesn’t
have a
driver stack (or lower device or pdo). It doesn’t even have a driver
object.
DriverEntry is not called until the OS has crashed. You’re not in the
normal
driver execution environment.

Jan

> Jan Bottorff wrote:
> >
> >
> >
> > I have a bus driver that talks to some of our function drivers. In
one
> > case it would be really useful to report the address of some non-
paged
> > pool (or perhaps allocated common memory) as a device memory
resource
> > via IRP_MN_QUERY_RESOURCES. I specifically want to do this so I
can
> > establish communication between my bus driver, a storport based
> > miniport and the crash dump twin of the storport based miniport
(and
> > perhaps even the hibernate twin).
> >
>
> Why can’t you just have the function drivers send an internal ioctl
to
> fetch the address of this shared area?

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

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

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

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