is it possible to know if a virtual address is unmapped or mapped at any moment?

NTDEV
1

HI,

In my driver i am accessing a memory address in my ISR but sometimes i am seeing a crash at that statement. I am suspecting that this crash is because that address has already been unmapped by the time i access it.

Is there anyway i can know if a virtual address is already unmapped? in other words is there an kernel mode API that tells me if an address is valid or not before i can access it?

Also one more question is can i map a physical address to virtual address twice in my driver? It doesn’t sound logical but just wanted to confirm on this.

2

You need to go back and read on the basics of memory access in the driver. Study what’s the difference between usermode address, system mapped address, etc.

3

If I may, I would add that ISRs should not do anything else then accessing the hardware. Every other task should be performed by a queued DPC.

But DPCs run at DISPATCH_LEVEL so you are not out of the wood because DPCs cannot access paged memory unless it has been locked. So you may need another level of queing involving a worker-thread that runs at passive level.

4

And how do they access the hardware without code in memory, and once they do
access the hardware where do they place results. Your statement is also a
gross generalization, since there are a lot of drivers where having the ISR
do more than just access the hardware and kick off a DPC is the only way to
get performance.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@live.fr
Sent: Thursday, August 07, 2014 3:56 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] is it possible to know if a virtual address is unmapped
or mapped at any moment?

If I may, I would add that ISRs should not do anything else then accessing
the hardware. Every other task should be performed by a queued DPC.

But DPCs run at DISPATCH_LEVEL so you are not out of the wood because DPCs
cannot access paged memory unless it has been locked. So you may need
another level of queing involving a worker-thread that runs at passive
level.

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

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

5

use MmIsAddressValid to check if memory address is valid before you access
it.

On Fri, Aug 8, 2014 at 1:36 AM, Don Burn wrote:

> And how do they access the hardware without code in memory, and once they
> do
> access the hardware where do they place results. Your statement is also a
> gross generalization, since there are a lot of drivers where having the ISR
> do more than just access the hardware and kick off a DPC is the only way to
> get performance.
>
>
> Don Burn
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
>
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@live.fr
> Sent: Thursday, August 07, 2014 3:56 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] is it possible to know if a virtual address is unmapped
> or mapped at any moment?
>
> If I may, I would add that ISRs should not do anything else then accessing
> the hardware. Every other task should be performed by a queued DPC.
>
> But DPCs run at DISPATCH_LEVEL so you are not out of the wood because DPCs
> cannot access paged memory unless it has been locked. So you may need
> another level of queing involving a worker-thread that runs at passive
> level.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> 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
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> 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
>

6

The fact that you’re in your ISR and trying to write to a virtual address that you haven’t ensured will remain mapped is your problem. You shouldn’t try to check if it’s valid, you ensure it will remain valid.

If it’s kernel memory you own, don’t free it until the ISR has run or until you’ve ensured it won’t try to write to it.
If it’s a buffer associated with an IRP, make sure you don’t complete the IRP until you’ve ensured the ISR won’t try to write to it
If it’s a user-mode buffer then map it into the kernel address space where the app can’t invalidate it, and unmap it after you’re done with it.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, August 7, 2014 12:00 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] is it possible to know if a virtual address is unmapped or mapped at any moment?

HI,

In my driver i am accessing a memory address in my ISR but sometimes i am seeing a crash at that statement. I am suspecting that this crash is because that address has already been unmapped by the time i access it.

Is there anyway i can know if a virtual address is already unmapped? in other words is there an kernel mode API that tells me if an address is valid or not before i can access it?

Also one more question is can i map a physical address to virtual address twice in my driver? It doesn’t sound logical but just wanted to confirm on this.

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

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

7

You are right Don. ISRs may access memory of course if they read/write data from/to the hardware but the buffer must be non-pageable or otherwise locked. Of course the code of the ISR must not be pageable because an ISR is supposed to run at device IRQL.

But I made this comment because I have read somewhere that ISRs preempt other code. That’s why they should do the minimum.

Note that MmAddressIsValid is not safe because a concurrent thread could release the buffer.

8

DO NOT USE MmAddressIsValid.

Your design is flawed if you are accessing wrong addresses. Then, even if MmAddressIsValid returns TRUE, it doesn’t mean it’s the memory you want to access.

9

Negative. This is just not safe. Consider the simple issue: You call MmIsAddressValid and it determine the page is resident. On the next instruction following the return, the page becomes non-resident.

This is a very commonly mis-used function, and it’s the reason it was left in NTDDK.H instead of being moved to WDM.H – The running joke is this function should be called "MmWasAddressValidJustAMicrosecondAgo(…)

As a general rule, if you’re calling a function that’s in NTDDK.H and not in WDM.H… ask youself why.

Peter
OSR
@OSRDrivers

10

Note that because the CPU saves the context of the currently running thread before invoking an ISR, the concept of thread context and consequently process context has no sense for an ISR. That’s why a user mode VA has no sense for an ISR. Therefore, an ISR should only access system space mappings and more precisely non-paged system mappings.


Is there any way i can know if a virtual address is already unmapped? in other words is there an kernel mode API that tells me if an address is valid or not before i can access it?

No, there is no (documented) way to do so. The MmIsAddressValid MSDN page has changed recently. A few months ago you could read this sentence on this page:

?Note that after this routine was called, if appropriate locks are not held, a non-faulting address could fault.?

These locks are two spin locks used internally by the OS, and of course, not exposed. One is held upon system mapping creation and the other is held upon system mapping deletion. In fact the OS creates/releases 2MB or 4MB chunks depending on the PAE mode.

So a MmIsAddressValid call would be safe only if the system VA deletion lock is held by the ISR before the call. Because MmIsAddressValid checks the page tables entries at every paging level for the corresponding VA and returns TRUE if the Valid bit is set at every paging level, holding the system VA deletion lock would assure you that the underlying physical page is present. The access is then safe from the “probed” VA to the next page boundary only.

If you suspect that another system component released a system mapping you have created, I think that is very unlikely because your driver is supposed to be the only one that knows the VA. Can a driver unmap hardware resources mapped by another driver ? To be honnest, I don’t know.

11

xxxxx@live.fr wrote:

Note that because the CPU saves the context of the currently running thread before invoking an ISR, the concept of thread context and consequently process context has no sense for an ISR. That’s why a user mode VA has no sense for an ISR. Therefore, an ISR should only access system space mappings and more precisely non-paged system mappings.

Your conclusion is correct, but I would word the premise a little
differently. An ISR DOES have a process context and a thread context,
but they have been stolen from someone else.

When I write code comments, I always say “running in an arbitrary context”.

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

12

Yes, this is right. I should have stated that though an ISR has a thread context, it is in fact the thread context of the CPU that the ISR is interrupting. The ISR is thus a code path, like a thread. The ISR gains execution because of a hardware event while a thread is created and scheduled by the OS.

13

actually the issue i am facing is like this.

I am observing a crash when i am updating my serial driver. On crash dump
analysis i am observing that the crash occurred in ISR while it is trying
to read a register using READ_REGISTER_UCHAR. Crash dump analysis says that
i tried to access NULL or completely invalid memory address at ISR level.

In the serial driver , during ReleaseHardware i am unmapping the system
memory that i allocated in PrepareHardWare. I am also making sure that
particular variable is set to NULL after memory is unmapped.

This crash is not happening in any other case so i think the address that i
am passing to READ_REGISTER_UCHAR is valid all the time. But only during
update somehow it is being invalid.

*Here is the design of my driver:*
.
I have two separate drivers. One controller driver for driving the
controller and a serial driver which controls all the ports on that
controller. Hence there will be multiple instances of serial port driver
whose device contexts will be passed to the controller driver and stored
during installation of serial drivers. these will be cleared during
uninstallation of serial driver.

During installation of the serial driver i am enabling the interrupts on
the serial port. because of this the serial port generates an interrupt
which results in controller driver ISR being called. Controller ISR checks
for an interrupt status register (using the mapped memory address passed to
it by port driver during initialization of the driver) and and calls a
function in serial port driver which does the actual job the servicing the
interrupt.

*More details on the issue:*
During updating a serial driver i am observing the crash of during the
READ_REGISTER_UCHAR function (which is protected by NULL checks for the
variables which hold the memory mapped addresses of serial driver). So the
address which i am passing to READ_REGISTER_UCHAR is not being NULL but it
is invalid.

I am unable to understand why this address could be invalid. The interrupt
should be generated only after i enabled the interrupts on the serial port
which requires me to write to a memory mapped register. That means i have
successfully mapped the serial port physical memory to virtual memory and
have a valid range of memory addresses with me.

J.S.R.Sarma.
9916109893.

On Sat, Aug 9, 2014 at 5:43 AM, wrote:

> Yes, this is right. I should have stated that though an ISR has a thread
> context, it is in fact the thread context of the CPU that the ISR is
> interrupting. The ISR is thus a code path, like a thread. The ISR gains
> execution because of a hardware event while a thread is created and
> scheduled by the OS.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> 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
>

14

The serial port generates this interrupt “X” immediately after i enable it
in the interrupt enable register of this port.

I am observing this crash in ISR only when i am enabling a specific
interrupt "X’ in DoEntry() function. When i enable this interrupt much
later, i.e. in the first write request that comes to the driver, i am not
facing any issue.

Hence phrasing my issue and my question in a more straight forward way,

*Issue:*

I am unable to access device registers immediately after i enable
interrupts in the serial port device. However i am able to access the
device registers after some duration.

*Question:*

When exactly it is safe to access the memory returned by MmapIoSpace()
function? Please note, *I need to access this memory from another driver.*

*It looks like it is too soon to touch this memory even during DoEntry()
function. I am currently mapping this physical memory in MmapIospace()
function. *

J.S.R.Sarma.
9916109893.

On Sat, Aug 9, 2014 at 11:25 AM, jayanth sharma
wrote:

> actually the issue i am facing is like this.
>
> I am observing a crash when i am updating my serial driver. On crash dump
> analysis i am observing that the crash occurred in ISR while it is trying
> to read a register using READ_REGISTER_UCHAR. Crash dump analysis says that
> i tried to access NULL or completely invalid memory address at ISR level.
>
> In the serial driver , during ReleaseHardware i am unmapping the system
> memory that i allocated in PrepareHardWare. I am also making sure that
> particular variable is set to NULL after memory is unmapped.
>
> This crash is not happening in any other case so i think the address that
> i am passing to READ_REGISTER_UCHAR is valid all the time. But only during
> update somehow it is being invalid.
>
> Here is the design of my driver:
> .
> I have two separate drivers. One controller driver for driving the
> controller and a serial driver which controls all the ports on that
> controller. Hence there will be multiple instances of serial port driver
> whose device contexts will be passed to the controller driver and stored
> during installation of serial drivers. these will be cleared during
> uninstallation of serial driver.
>
> During installation of the serial driver i am enabling the interrupts on
> the serial port. because of this the serial port generates an interrupt
> which results in controller driver ISR being called. Controller ISR checks
> for an interrupt status register (using the mapped memory address passed to
> it by port driver during initialization of the driver) and and calls a
> function in serial port driver which does the actual job the servicing the
> interrupt.
>
> More details on the issue:
> During updating a serial driver i am observing the crash of during the
> READ_REGISTER_UCHAR function (which is protected by NULL checks for the
> variables which hold the memory mapped addresses of serial driver). So the
> address which i am passing to READ_REGISTER_UCHAR is not being NULL but it
> is invalid.
>
> I am unable to understand why this address could be invalid. The interrupt
> should be generated only after i enabled the interrupts on the serial port
> which requires me to write to a memory mapped register. That means i have
> successfully mapped the serial port physical memory to virtual memory and
> have a valid range of memory addresses with me.
>
>
>
>
>
> J.S.R.Sarma.
> 9916109893.
>
>
> On Sat, Aug 9, 2014 at 5:43 AM, wrote:
>
>> Yes, this is right. I should have stated that though an ISR has a thread
>> context, it is in fact the thread context of the CPU that the ISR is
>> interrupting. The ISR is thus a code path, like a thread. The ISR gains
>> execution because of a hardware event while a thread is created and
>> scheduled by the OS.
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> 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
>>
>
>

15

On Aug 8, 2014, at 10:55 PM, jayanth sharma > wrote:

I am observing a crash when i am updating my serial driver. On crash dump analysis i am observing that the crash occurred in ISR while it is trying to read a register using READ_REGISTER_UCHAR. Crash dump analysis says that i tried to access NULL or completely invalid memory address at ISR level.

Well, which is it? NULL or invalid? Is it happening on the shutdown of the old driver, or the bring up of the new driver? Are you absolutely sure the old driver is getting unloaded before the new driver loads?

Here is the design of my driver:
.
I have two separate drivers. One controller driver for driving the controller and a serial driver which controls all the ports on that controller. Hence there will be multiple instances of serial port driver whose device contexts will be passed to the controller driver and stored during installation of serial drivers. these will be cleared during uninstallation of serial driver.

So is this a normal PnP setup, where your controller is a bus driver that creates PDOs for the serial driver?

During installation of the serial driver i am enabling the interrupts on the serial port. because of this the serial port generates an interrupt which results in controller driver ISR being called. Controller ISR checks for an interrupt status register (using the mapped memory address passed to it by port driver during initialization of the driver) and and calls a function in serial port driver which does the actual job the servicing the interrupt.

That is a somewhat dangerous proposition, because you are asking the controller/bus driver to manipulate resources it doesn?t manage. When you unmap the memory in the child driver, do you notify the parent bus driver that the address is no longer valid?
–
Tim Roberts, xxxxx@probo.commailto:xxxxx
Providenza & Boekelheide, Inc.</mailto:xxxxx>

16

Tim,

I am sure it is not NULL. because the function READ_REGISTER_UCHAR() is
protected by NULL checks for the memory it is trying to read. It can only
be invalid.

J.S.R.Sarma.
9916109893.

On Sat, Aug 9, 2014 at 12:35 PM, Tim Roberts wrote:

> On Aug 8, 2014, at 10:55 PM, jayanth sharma
> wrote:
>
>
> I am observing a crash when i am updating my serial driver. On crash dump
> analysis i am observing that the crash occurred in ISR while it is trying
> to read a register using READ_REGISTER_UCHAR. Crash dump analysis says that
> i tried to access NULL or completely invalid memory address at ISR level.
>
>
> Well, which is it? NULL or invalid? Is it happening on the shutdown of
> the old driver, or the bring up of the new driver? Are you absolutely sure
> the old driver is getting unloaded before the new driver loads?
>
>
> Here is the design of my driver:
> .
> I have two separate drivers. One controller driver for driving the
> controller and a serial driver which controls all the ports on that
> controller. Hence there will be multiple instances of serial port driver
> whose device contexts will be passed to the controller driver and stored
> during installation of serial drivers. these will be cleared during
> uninstallation of serial driver.
>
>
> So is this a normal PnP setup, where your controller is a bus driver that
> creates PDOs for the serial driver?
>
>
> During installation of the serial driver i am enabling the interrupts on
> the serial port. because of this the serial port generates an interrupt
> which results in controller driver ISR being called. Controller ISR checks
> for an interrupt status register (using the mapped memory address passed to
> it by port driver during initialization of the driver) and and calls a
> function in serial port driver which does the actual job the servicing the
> interrupt.
>
>
> That is a somewhat dangerous proposition, because you are asking the
> controller/bus driver to manipulate resources it doesn’t manage. When you
> unmap the memory in the child driver, do you notify the parent bus driver
> that the address is no longer valid?
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> 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
>

17
  1. I am updating the driver from the device manager. Hence i assumed
    windows will uninstall the driver completely before installing the new
    driver. Please let me know if i am wrong in this assumption.

If this is a possibiliy then how can i make windows not install the new
driver unless the old driver is completely uninstalled?

  1. Yes. The setup is same as what you described. however the controller is
    the only PnP device here i guess. because the ports on the controller are
    not removable.

  2. When i unmap the memory in the child driver, i am making the variables
    that hold the memory address NULL, and i am making sure to make NULL the
    variables in teh controller driver that were updated with child devices
    memory addresses earlier. Is there anything i am forgetting to do here? or
    this should be sufficient?

J.S.R.Sarma.
9916109893.

On Sat, Aug 9, 2014 at 12:50 PM, jayanth sharma
wrote:

> Tim,
>
> I am sure it is not NULL. because the function READ_REGISTER_UCHAR() is
> protected by NULL checks for the memory it is trying to read. It can only
> be invalid.
>
>
>
>
>
> J.S.R.Sarma.
> 9916109893.
>
>
> On Sat, Aug 9, 2014 at 12:35 PM, Tim Roberts wrote:
>
>> On Aug 8, 2014, at 10:55 PM, jayanth sharma
>> wrote:
>>
>>
>> I am observing a crash when i am updating my serial driver. On crash dump
>> analysis i am observing that the crash occurred in ISR while it is trying
>> to read a register using READ_REGISTER_UCHAR. Crash dump analysis says that
>> i tried to access NULL or completely invalid memory address at ISR level.
>>
>>
>> Well, which is it? NULL or invalid? Is it happening on the shutdown of
>> the old driver, or the bring up of the new driver? Are you absolutely sure
>> the old driver is getting unloaded before the new driver loads?
>>
>>
>> Here is the design of my driver:
>> .
>> I have two separate drivers. One controller driver for driving the
>> controller and a serial driver which controls all the ports on that
>> controller. Hence there will be multiple instances of serial port driver
>> whose device contexts will be passed to the controller driver and stored
>> during installation of serial drivers. these will be cleared during
>> uninstallation of serial driver.
>>
>>
>> So is this a normal PnP setup, where your controller is a bus driver that
>> creates PDOs for the serial driver?
>>
>>
>> During installation of the serial driver i am enabling the interrupts on
>> the serial port. because of this the serial port generates an interrupt
>> which results in controller driver ISR being called. Controller ISR checks
>> for an interrupt status register (using the mapped memory address passed to
>> it by port driver during initialization of the driver) and and calls a
>> function in serial port driver which does the actual job the servicing the
>> interrupt.
>>
>>
>> That is a somewhat dangerous proposition, because you are asking the
>> controller/bus driver to manipulate resources it doesn’t manage. When you
>> unmap the memory in the child driver, do you notify the parent bus driver
>> that the address is no longer valid?
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> 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
>>
>
>

18

Do you use KMDF ?

What does the debugger tells you about the memory mapped address ? Can you run the !pte debugger command with the address returned by MmMapIoSpace as argument ?

19

Miles90,

I can run the command certainly. however one small query is that how to
note down the memory address returned by MmMapioSpace() , since this system
is crashing even before i could see the logs.

Due to some hardware limitations,i can’t perform Kernel debugging for my
driver using WinDbG here and that is killing a lot of time for me.

Can i store the DbgView logs in a remote machine so that i can save the
logs in event of a crash?

Tim,

I agree that the design is somewhat inconsistent with the norms, but i
don’t have any other way to determine which of the child devices caused the
interrupt.

There is a global register in every child device that holds the information
of which child caused the interrupt. In my parent driver ISR i determine
the child device for which the memory has been mapped and is accessible
currently, and using that child devices base memory address i read this
global register to determine which bit is set in this register. this tells
me which child devcie caused the interrupt. Then i dispatch the interrupt
to that child device by calling it’s ISR function (which was registered to
parent device using QueryInterface method while the child device loads).

I could have however designed this part in an alternative way.
I could pass delegate the interrupt in teh parent driver to each of the
child devices and in the child devices, determine, if the interrupt is
intended to this child device or not. but this will increase teh latency of
ISR which increases the overall latency.

J.S.R.Sarma.
9916109893.

On Sat, Aug 9, 2014 at 12:58 PM, wrote:

> Do you use KMDF ?
>
> What does the debugger tells you about the memory mapped address ? Can you
> run the !pte debugger command with the address returned by MmMapIoSpace as
> argument ?
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> 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
>

20

Oh by the way, I use KMDF. Sorry for spamming.

J.S.R.Sarma.
9916109893.

On Sat, Aug 9, 2014 at 1:11 PM, jayanth sharma
wrote:

> Miles90,
>
> I can run the command certainly. however one small query is that how to
> note down the memory address returned by MmMapioSpace() , since this system
> is crashing even before i could see the logs.
>
> Due to some hardware limitations,i can’t perform Kernel debugging for my
> driver using WinDbG here and that is killing a lot of time for me.
>
> Can i store the DbgView logs in a remote machine so that i can save the
> logs in event of a crash?
>
> Tim,
>
> I agree that the design is somewhat inconsistent with the norms, but i
> don’t have any other way to determine which of the child devices caused the
> interrupt.
>
> There is a global register in every child device that holds the
> information of which child caused the interrupt. In my parent driver ISR i
> determine the child device for which the memory has been mapped and is
> accessible currently, and using that child devices base memory address i
> read this global register to determine which bit is set in this register.
> this tells me which child devcie caused the interrupt. Then i dispatch the
> interrupt to that child device by calling it’s ISR function (which was
> registered to parent device using QueryInterface method while the child
> device loads).
>
> I could have however designed this part in an alternative way.
> I could pass delegate the interrupt in teh parent driver to each of the
> child devices and in the child devices, determine, if the interrupt is
> intended to this child device or not. but this will increase teh latency of
> ISR which increases the overall latency.
>
>
>
> J.S.R.Sarma.
> 9916109893.
>
>
> On Sat, Aug 9, 2014 at 12:58 PM, wrote:
>
>> Do you use KMDF ?
>>
>> What does the debugger tells you about the memory mapped address ? Can
>> you run the !pte debugger command with the address returned by MmMapIoSpace
>> as argument ?
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> 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
>>
>
>