Filtering ACPIEC

Attempting to filter an ACPI-compliant embedded controller on the motherboard (not the keyboard controller). Started with sample code from KMDF Toaster filter and KMDF keyboard filter (using a raw PDO for sideband comms from user app). First time on APCI stuff.

Device is PNP0C09. Driver is ACPIEC.

Wrote a filter and attempted to filter ACPIEC. Have been unsuccessful in getting callbacks to hit for my queues. Tried installing (with INF, or manually) as an upper to ACPIEC, and as a lower to ACPIEC. Behavior is different, depending on where its installed:

Upper - only callbacks that work are DriverEntry and DeviceAdd. No IRP callbacks are hit. Breakpoints are set at entry of each callback. No breaks, and no debug messages in WinDbg.

Lower - can see callbacks (via kdprint to WinDbg) for DriverEntry, DeviceAdd, and default queue are executed, but breakpoints do not function. Again, breakpoints set at entry of each callback, but execution does not halt. My debug messages scroll right on by, as does execution…

I have never successfully gotten a hit for any of the following queues: ioctrl, internal ioctrl, read, or write. Used IRPTracker to verify that there are IRPs of those types flowing to the device and to the driver.

Filter driver is installed as SERVICE_BOOT_START, as is the WDF co-installer. Verified that the UpperFilters entry exists on the PNP0C09 registry entry under \Current Control Set\Enum\ACPI (when installed as an upper). Have been using Filterman to change the position of the filter, as I have been unable to figure out exactly where it goes using manual methods. There is a registry key for my driver.

Driver registers as a filter via WdfFdoInitSetFilter, and its before the WdfDeviceCreate call. Queues are set up for each IRP, and a WdfDeviceConfigureRequestDispatching call made to ensure that IRPs of each type are sent to the proper queue.

Calls to raw PDO (sideband) from a user-mode app work fine, and can be tracked in IRPTracker.

IRPTracker shows nothing for my device. Its as if I’m attached to nothing at all (or getting bypassed), though I get that DeviceAdd callback to hit when I’m an upper to ACPIEC.

I need a hint. How do I receive IRPs bound for ACPIEC, as an upper filter? Maybe a better question is, how do I filter the stack for PNP0C09 (ACPI-compliant embedded controller)? Where do I attach, and how do I receive IRPs bound for the device?

Where exactly does the UpperFilters entry go for the device I’m trying to filter? There are three control sets in the registry, and it isn’t clear which one is being used.

Been beating my head against a wall. Any advice would be appreciated. Thanks in advance.

FIRST, let me thank you for what is a very clear, comprehensive, and intelligent statement of your problem, what you’ve tried, and what you’ve observed.

I initially was going to pass on even trying to analyze this problem, because anything involving ACPI I usually leave to JakeO to answer (sorry Jake). But as I re-read your problem statement, I think I’ve come to the conclusion that your problem isn’t ACPI-related at all. Your problem is: “My filter doesn’t work, how am I supposed to install it?” Or, at least I hope that’s your problem, because I don’t know anything at all about the ACPI EC driver.

I suspect your filter isn’t installing in the right place. Because if it were, you’d be seeing the I/O operations that you say are flowing to the device.

I’ll suggest what I suggested earlier to somebody ELSE with a similar filter-driver problem: Diagram the FDOs and PDOs that are of interest to you. I, personally, would use Device Tree. Start by looking for the device objects created by the ACPIEC driver (by driver name) then locate these device objects in the tree view section. Look to see the PDO and FDO relationships. Also, find where YOUR driver is. Remember, devices within a devnode are attached via the AttachedDevice field of the device object. You should see PDO->AttachDevice pointing to FDO and FDO->AttachedDevice pointing to your upper filter.

Correlate the device objects you find with I/O using IrpTracker. Where’s the I/O Flowing? Is your driver in the path?

All requests to a device object in a devnode enter that devnode at the TOP. This is a rule. That’s why upper filters work.

In terms of:

Always use the one named CurrentControlSet… this is an alias for the control set that’s being used.

I hope that helps,

Peter
OSR

I would make sure the target devstack actually talks in?IRPs before I even start thinking of writing a IRP filter. This can be observed by dumping all dispatch routine entry points?of each drivers in the stack, then?set bp?on the ones you’re interested. make sure the bp is hit.
?
To see?where?you are at,?use !devstack any_dev_obj_in_the_stack.
?

Calvin Guan
Broadcom Corp.
Connecting Everything(r)?

— On Thu, 2/19/09, xxxxx@osr.com wrote:

From: xxxxx@osr.com
Subject: RE:[ntdev] Filtering ACPIEC
To: “Windows System Software Devs Interest List”
Date: Thursday, February 19, 2009, 3:23 PM

FIRST, let me thank you for what is a very clear, comprehensive, and intelligent statement of your problem, what you’ve tried, and what you’ve observed.

I initially was going to pass on even trying to analyze this problem, because anything involving ACPI I usually leave to JakeO to answer (sorry Jake).? But as I re-read your problem statement, I think I’ve come to the conclusion that your problem isn’t ACPI-related at all.? Your problem is: “My filter doesn’t work, how am I supposed to install it?”???Or, at least I hope that’s your problem, because I don’t know anything at all about the ACPI EC driver.

I suspect your filter isn’t installing in the right place.? Because if it were, you’d be seeing the I/O operations that you say are flowing to the device.

I’ll suggest what I suggested earlier to somebody ELSE with a similar filter-driver problem:? Diagram the FDOs and PDOs that are of interest to you.? I, personally, would use Device Tree.? Start by looking for the device objects created by the ACPIEC driver (by driver name) then locate these device objects in the tree view section.? Look to see the PDO and FDO relationships.? Also, find where YOUR driver is.? Remember, devices within a devnode are attached via the AttachedDevice field of the device object.? You should see PDO->AttachDevice pointing to FDO and FDO->AttachedDevice pointing to your upper filter.

Correlate the device objects you find with I/O using IrpTracker.? Where’s the I/O Flowing?? Is your driver in the path?

All requests to a device object in a devnode enter that devnode at the TOP.? This is a rule.? That’s why upper filters work.

In terms of:



Always use the one named CurrentControlSet… this is an alias for the control set that’s being used.

I hope that helps,

Peter
OSR


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

Thanks. I try to give people the info I would want when coming in cold on a problem.

I believe it could be an install problem also, but not yet convinced.

DeviceTree has been very useful. Used DeviceTree to do the mapping, and cross-referenced with Filterman observations. They both show the filter installed where I think it should be - either above or below ACPIEC, as installed. Also followed the chain through WinDbg using !devobj and !drvobj, starting with !object acpiec.sys, and working my way downward. DeviceTree chain, as follows, when installed as an upper filter to ACPIEC:

ENM \Device\PnPManager

FDO \Device\0000005F
FDO Attached: (unnamed) - \Driver\isapnp
PDO \Device\00000067 [ACPI\PNP0C09]
FDO \Device\ACPIEC
FDO Attached: (unnamed) - \Driver<myfilter>

Regarding manual installation of an UpperFilters entry on an existing device, the thing I discovered about CurrentControlSet, and manual entries, is that you cannot add an entry to the device in the Enum section - where the actual device is enumerated with its unique number:

CurrentControlSet\Enum\ACPI\PNP0C09\4&2FFE84EA&0

In this section, I see that the UpperFilters entry is there with . Attempts to add a key for LowerFilters, or delete the UpperFilters key are met with resistance. I would hazard a guess that the enumerated section is getting its data from other places in the registry during the enumeration, but I haven’t found where, exactly, despite a long search.

Using !devstack on acpiec yields the following:

0: kd> !devstack acpiec
!DevObj !DrvObj !DevExt ObjectName
8a8bcf00 \Driver\swfilt 8a937550

8a9376c8 \Driver\ACPIEC 8a937780 ACPIEC
8a938738 \Driver\ACPI 8a949298 00000067
!DevNode 8a8cd968 :
DeviceInst is “ACPI\PNP0C09\4&2ffe84ea&0”
ServiceName is “ACPIEC”

IRPTracker shows read and write requests to ACPIEC. It also shows ioctrl requests (ACPI_ASYNC_EVAL_METHOD) going to the device itself. The call sequence looks as follows:

Call \Device\00000067 DEVICE_CONTROL (ACPI_ASYNC_EVAL_METHOD)
Call \Device\ACPIEC READ
Comp
Comp Routine
Call \Device\ACPIEC READ
Comp
Comp Routine
Call \Device\ACPIEC WRITE
Comp
Comp Routine

Comp \Device\00000067
Comp Routine

The point being, the ioctrl call to the device (and subsequent completion 16ms later) bracketing all the READS and WRITES to ACPIEC. From this observation, I deduced that the stack uses IRPs.

IRPTracker reports unknown process for all calls. I’m assuming its the kernel itself, even though they aren’t internal ioctrl calls.

Sorry Peter, you should have left this one to me.

Ewright, you’re going to have a hard time making this work. It would have
worked well on XP and earlier systems, assuming that you got your
installation issues sorted out. I’ve seen people do this before.

With Vista, the team that now owns this code subsumed ACPI EC management
into ACPI.sys and stopped building a driver stack for it. It didn’t occur
to them that anybody would ever need to filter it. So anything you get
working on XP is just going to break with Vista. I pointed this out to them
the last time this subject came up on this list and the best response I got
amounted to “oops, I guess we don’t allow that any more.”

It is important to note, though, that this was never a supported scenario.
If you’re willing to back up and tell me what you’re actually trying to
accomplish, I might be able to help.


Jake Oshins
Hyper-V I/O Architect (former ACPI guy)
Windows Kernel Team

This post implies no warranties and confers no rights.


wrote in message news:xxxxx@ntdev…
> FIRST, let me thank you for what is a very clear, comprehensive, and
> intelligent statement of your problem, what you’ve tried, and what you’ve
> observed.
>
> I initially was going to pass on even trying to analyze this problem,
> because anything involving ACPI I usually leave to JakeO to answer (sorry
> Jake). But as I re-read your problem statement, I think I’ve come to the
> conclusion that your problem isn’t ACPI-related at all. Your problem is:
> “My filter doesn’t work, how am I supposed to install it?” Or, at least
> I hope that’s your problem, because I don’t know anything at all about the
> ACPI EC driver.
>
> I suspect your filter isn’t installing in the right place. Because if it
> were, you’d be seeing the I/O operations that you say are flowing to the
> device.
>
> I’ll suggest what I suggested earlier to somebody ELSE with a similar
> filter-driver problem: Diagram the FDOs and PDOs that are of interest to
> you. I, personally, would use Device Tree. Start by looking for the
> device objects created by the ACPIEC driver (by driver name) then locate
> these device objects in the tree view section. Look to see the PDO and
> FDO relationships. Also, find where YOUR driver is. Remember, devices
> within a devnode are attached via the AttachedDevice field of the device
> object. You should see PDO->AttachDevice pointing to FDO and
> FDO->AttachedDevice pointing to your upper filter.
>
> Correlate the device objects you find with I/O using IrpTracker. Where’s
> the I/O Flowing? Is your driver in the path?
>
> All requests to a device object in a devnode enter that devnode at the
> TOP. This is a rule. That’s why upper filters work.
>
> In terms of:
>


>
> Always use the one named CurrentControlSet… this is an alias for the
> control set that’s being used.
>
> I hope that helps,
>
> Peter
> OSR
>
>
>
>

Jake,

I appreciate your info (and from others also, thanks). Its XP at the moment, so I guess there is mixed news in your response. I may get it to work now, but I’m one extended support announcement from having it break. I’d like to get something working on XP first, and then deal with the Vista problem.

I have a motherboard with an ACPI-compliant embedded controller. Command register is at 0x62 and status register is at 0x66. There also appears to be memory mapped space, where the real work is done. I want access to the methods targeted at the embedded controller. I want to see them (first), and then I want to call them. I can correlate activity on the motherboard to IRPs going through ACPIEC and the device itself, so I know I’m looking in the right place. I just can’t seem to get my filter’s callbacks to capture requests bound for ACPIEC.

You didn’t really answer my question. What are you trying to accomplish?
Saying that you want to see and invoke methods tells me how you think you
want to accomplish that which you’re trying to accomplish. Tell me what the
goal is and I can probably tell you how to do it.


Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team

This post implies no warranties and confers no rights.


wrote in message news:xxxxx@ntdev…
> Jake,
>
> I appreciate your info (and from others also, thanks). Its XP at the
> moment, so I guess there is mixed news in your response. I may get it to
> work now, but I’m one extended support announcement from having it break.
> I’d like to get something working on XP first, and then deal with the
> Vista problem.
>
> I have a motherboard with an ACPI-compliant embedded controller. Command
> register is at 0x62 and status register is at 0x66. There also appears to
> be memory mapped space, where the real work is done. I want access to the
> methods targeted at the embedded controller. I want to see them (first),
> and then I want to call them. I can correlate activity on the motherboard
> to IRPs going through ACPIEC and the device itself, so I know I’m looking
> in the right place. I just can’t seem to get my filter’s callbacks to
> capture requests bound for ACPIEC.
>

The goal is to read, modify, or write commands to the ancillary embedded controller. It seemed to me that working through the set of commands defined in the methods, and working from the top of the stack, was the right way to accomplish that goal.

Seeing what goes down the stack, and when, was the first step in understanding - I’m new to ACPI. So there are a couple of things I’d like to get done. First, get the upper filter I’ve been hammering on installed/configured correctly so that I can see the requests going into the stack. That would give me some information to work with. Second is to code something (different) that will work beyond XP, given the new information (acpiec folding into apci).

I initially thought of filtering on ACPI, but I didn’t want to deal with the firehose of data going back and forth - CDRom polls, etc. I’m only interested in the secondary embedded controller.

The filter I have coded runs AddDevice during boot, and sets up all the queues - verified using the wdf extensions in WinDbg. There are currently queues set up for ioctrl, internal ioctrl, read, write, and default. The last one was added in an attempt to get something to trigger. No dice.

IRPTracker shows read and write calls into acpiec, and ioctrl (ASYNC_EVAL_METHOD) calls going into the device itself. As an upper, I should be able to see the read and write calls going in. As a lower, I should be able to see the ioctrl calls going out. Correct?

The fact that AddDevice was run, I thought, was some indication that I was on the stack. I also do an InitQueryProperty call from within AddDevice and pull the device name - its what I think it shoudl be.

Thanks for your help.

I’m sorry, but you still didn’t answer my question, you just elaborated on
the fact that you want to filter ACPI. It’s possible to get that working
under XP. But it’s not possible after XP. As ACPI.sys is the consumer of
the embedded controller, there are no IRPs after XP. Filtering ACPI itself
would have no effect. (And it would be stunningly complex, as ACPI is by
far the most complicated PnP driver ever written.)

If your only goal is to understand things, ask questions. If you have an
actual engineering goal, let me know and I’ll try to help accomplish it.


Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team

This post implies no warranties and confers no rights.


wrote in message news:xxxxx@ntdev…
> The goal is to read, modify, or write commands to the ancillary embedded
> controller. It seemed to me that working through the set of commands
> defined in the methods, and working from the top of the stack, was the
> right way to accomplish that goal.
>
> Seeing what goes down the stack, and when, was the first step in
> understanding - I’m new to ACPI. So there are a couple of things I’d like
> to get done. First, get the upper filter I’ve been hammering on
> installed/configured correctly so that I can see the requests going into
> the stack. That would give me some information to work with. Second is
> to code something (different) that will work beyond XP, given the new
> information (acpiec folding into apci).
>
> I initially thought of filtering on ACPI, but I didn’t want to deal with
> the firehose of data going back and forth - CDRom polls, etc. I’m only
> interested in the secondary embedded controller.
>
> The filter I have coded runs AddDevice during boot, and sets up all the
> queues - verified using the wdf extensions in WinDbg. There are currently
> queues set up for ioctrl, internal ioctrl, read, write, and default. The
> last one was added in an attempt to get something to trigger. No dice.
>
> IRPTracker shows read and write calls into acpiec, and ioctrl
> (ASYNC_EVAL_METHOD) calls going into the device itself. As an upper, I
> should be able to see the read and write calls going in. As a lower, I
> should be able to see the ioctrl calls going out. Correct?
>
> The fact that AddDevice was run, I thought, was some indication that I was
> on the stack. I also do an InitQueryProperty call from within AddDevice
> and pull the device name - its what I think it shoudl be.
>
> Thanks for your help.
>

I apologize. I think I am answering the question. The goal is to read, modify, or write commands to the ancillary embedded controller, through the use of a filter on its existing stack. Its for a lab setup to facilitate in-house hardware testing, not production code. Hence, Vista compatibility gong forward isn’t a high priority at the moment, but certainly worth considering.

That is the goal.

>the FDOs and PDOs that are of interest to you. I, personally, would use Device Tree.

WinDbg’s !object and !devobj can also help a lot.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Yes, Maxim, thank you. I have been using !object and !devobj to map out the stack. Also been using the !wdf extensions to verify that I have the queues and callbacks set up for my filter correctly. As follows:

0: kd> !devobj \Device\00000067
Device object (8a938738) is for:
00000067 \Driver\ACPI DriverObject 8a998030
Current Irp 00000000 RefCount 0 Type 00000032 Flags 00001040
Dacl e19a2cec DevExt 8a949298 DevObjExt 8a9387f0 DevNode 8a8cd968
ExtensionFlags (0000000000)
AttachedDevice (Upper) 8a9376c8 \Driver\ACPIEC
Device queue is not busy.

0: kd> !drvobj labfilt
Driver object (8a937bb8) is for:
\Driver\labfilt
Driver Extension List: (id , addr)
(b9f0d569 8a995af8)
Device Object list:
8a908a10 8a8bcf00

0: kd> !wdfdriverinfo labfilt

Default driver image name: labfilt
WDF library image name: wdf01000
FxDriverGlobals 0x8a937aa0
WdfBindInfo 0xba33ad30
Version v1.7 build(6001)

WDFDRIVER: 0x7567fd40

!WDFDEVICE 0x756c8c70
context: dt 0x8a937550 DEVICE_EXTENSION (size is 0x148 bytes)


!WDFDEVICE 0x75743cd8
context: dt 0x8a8bc4e8 RPDO_DEVICE_DATA (size is 0x4 bytes)

----------------------------------

0: kd> !wdfhandle 0x7567fd40 0x30

Dumping WDFHANDLE 0x7567fd40
=============================
Handle type is WDFDRIVER
Refcount: 1
Contexts:


Child WDFHANDLEs of 0x7567fd40:
!WDFDRIVER 0x7567fd40


!WDFDEVICE 0x756c8c70
context: dt 0x8a937550 DEVICE_EXTENSION (size is 0x148 bytes)


!WDFQUEUE 0x75743308


!WDFQUEUE 0x75743508


!WDFQUEUE 0x75743708


!WDFQUEUE 0x75743908


!WDFCMRESLIST 0x75742870


!WDFCMRESLIST 0x75731eb0


!WDFCHILDLIST 0x756c8e40


!WDFIOTARGET 0x7568b0c0


!WDFDEVICE 0x75743cd8
context: dt 0x8a8bc4e8 RPDO_DEVICE_DATA (size is 0x4 bytes)


!WDFQUEUE 0x756f7808


!WDFCMRESLIST 0x756d9de8


!WDFCMRESLIST 0x75666f18


!wdfobject 0x8a9802b8

0: kd> !wdfdevicequeues 0x756c8c70

Dumping queues of WDFDEVICE 0x756c8c70
=====================================
Number of queues: 4
----------------------------------
Queue: 1 (!wdfqueue 0x75743308)
Sequential, Default, Not power-managed, PowerOn, Can accept, Can dispatch, ExecutionLevelDispatch, SynchronizationScopeNone
Number of driver owned requests: 0
Number of waiting requests: 0

EvtIoDefault: (0xba3389f0) labfilt!Filter_EvtIoDefault
----------------------------------
Queue: 2 (!wdfqueue 0x75743508)
Sequential, Not power-managed, PowerOn, Can accept, Can dispatch, ExecutionLevelDispatch, SynchronizationScopeNone
Number of driver owned requests: 0
Number of waiting requests: 0

EvtIoInternalDeviceControl: (0xba338740) labfilt!Filter_EvtIoInternalDeviceControl
----------------------------------
Queue: 3 (!wdfqueue 0x75743708)
Sequential, Not power-managed, PowerOn, Can accept, Can dispatch, ExecutionLevelDispatch, SynchronizationScopeNone
Number of driver owned requests: 0
Number of waiting requests: 0

EvtIoRead: (0xba338910) labfilt!Filter_EvtIoRead
----------------------------------
Queue: 4 (!wdfqueue 0x75743908)
Sequential, Not power-managed, PowerOn, Can accept, Can dispatch, ExecutionLevelDispatch, SynchronizationScopeNone
Number of driver owned requests: 0
Number of waiting requests: 0

EvtIoWrite: (0xba338980) labfilt!Filter_EvtIoWrite

0: kd> !devobj acpiec
Device object (8a9376c8) is for:
ACPIEC \Driver\ACPIEC DriverObject 8a937cb0
Current Irp 00000000 RefCount 0 Type 00000022 Flags 00002044
Dacl e19a2cec DevExt 8a937780 DevObjExt 8a937a68
ExtensionFlags (0000000000)
AttachedDevice (Upper) 8a8bcf00 \Driver\labfilt
AttachedTo (Lower) 8a938738 \Driver\ACPI
Device queue is not busy.

0: kd> !object \driver\acpiec
Object: 8a937cb0 Type: (8a967ad0) Driver
ObjectHeader: 8a937c98 (old version)
HandleCount: 0 PointerCount: 3
Directory Object: e199c510 Name: ACPIEC

There has been some progress, in that I managed to get breakpoints working when installed as a lower filter to ACPIEC. When installed as a lower, I will get the entry and DeviceAdd callbacks, and two ioctrl callbacks during boot:

32C004 = ACPI, read and write, method buffered, Func 0x01
32C008 = ACPI, read and write, method buffered, Func 0x02

After that, no additional callbacks get hit, even though there is additional ioctrl activity in IRPTracker.

If installed as an upper filter to ACPIEC, only get the entry and DeviceAdd callbacks. No I/O callbacks get hit.

Read, modify, or write commands to the EC to accomplish…

- S

-----Original Message-----
From: xxxxx@base2engineering.com
Sent: Friday, February 20, 2009 08:32
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Filtering ACPIEC

I apologize. I think I am answering the question. The goal is to read, modify, or write commands to the ancillary embedded controller, through the use of a filter on its existing stack. Its for a lab setup to facilitate in-house hardware testing, not production code. Hence, Vista compatibility gong forward isn’t a high priority at the moment, but certainly worth considering.

That is the goal.


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

Ah. Hardware testing. That was the answer that I was looking for.

I suggest that you don’t use Windows. You’re going to waste a tremendous
amount of time trying to stay in synch with ACPI and in the end it will be
nearly impossible.

This is why most hardware tests execute under DOS or EFI.


Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team

This post implies no warranties and confers no rights.


wrote in message news:xxxxx@ntdev…
> I apologize. I think I am answering the question. The goal is to read,
> modify, or write commands to the ancillary embedded controller, through
> the use of a filter on its existing stack. Its for a lab setup to
> facilitate in-house hardware testing, not production code. Hence, Vista
> compatibility gong forward isn’t a high priority at the moment, but
> certainly worth considering.
>
> That is the goal.
>
>
>

Well… its testing of other software that interacts with hardware. The purpose of the filter is to be a control mechanism during testing. The embedded controller operates features on the motherboard that we want to monitor and tweak. The purpose of monitoring and tweaking is closed-loop verification of other software in the system. Good or bad, that is the task. I’m paid to be hard-headed… :slight_smile:

Given that its XP, given that its not necessary to be forward compatible into Vista, and given that it should be possible to filter acpiec in XP in order to monitor/tweak the embedded controller, I would appreciate some advice on where the problem may be.

Installed as a lower filter, I get two ioctrl calls, as mentioned previously. For the ASYNC_EVAL_METHOD call (0x32C004), the corresponding buffer has a “AeiB_GPE” signature. The remaining requests that I see in IRPTracker (once boot up is complete and it can be executed) do not hit the callbacks.

Installed as an upper filter, no event callbacks ever hit for read, write, or ioctrl calls. Only calls that hit are Entry and DeviceAdd.

Preference would be to be an upper filter to something in the stack that ultimately ends at the embedded controller. Ideally, at the top. If acpiec is not the right place to do that, then where?

Any advice on how to accomplish the task would be appreciated. “Don’t do that”, unfortunately, is not an an option for me. Thanks in advance for any advice you may have to offer.

To remove misconfiguration from the equation, install your driver on top of serial.sys (or a modem stack) and open up hypertrm and see if you can capture the IOCTLs, reads and writes. Or create your own root devnode and dump FDO that completes all IO, add your filter to it and write a simple app that sends reads, writes and IOCTLs and see if hits in your filter. That at least removes one variable from the debugging equation.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@base2engineering.com
Sent: Friday, February 20, 2009 3:58 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Filtering ACPIEC

Well… its testing of other software that interacts with hardware. The purpose of the filter is to be a control mechanism during testing. The embedded controller operates features on the motherboard that we want to monitor and tweak. The purpose of monitoring and tweaking is closed-loop verification of other software in the system. Good or bad, that is the task. I’m paid to be hard-headed… :slight_smile:

Given that its XP, given that its not necessary to be forward compatible into Vista, and given that it should be possible to filter acpiec in XP in order to monitor/tweak the embedded controller, I would appreciate some advice on where the problem may be.

Installed as a lower filter, I get two ioctrl calls, as mentioned previously. For the ASYNC_EVAL_METHOD call (0x32C004), the corresponding buffer has a “AeiB_GPE” signature. The remaining requests that I see in IRPTracker (once boot up is complete and it can be executed) do not hit the callbacks.

Installed as an upper filter, no event callbacks ever hit for read, write, or ioctrl calls. Only calls that hit are Entry and DeviceAdd.

Preference would be to be an upper filter to something in the stack that ultimately ends at the embedded controller. Ideally, at the top. If acpiec is not the right place to do that, then where?

Any advice on how to accomplish the task would be appreciated. “Don’t do that”, unfortunately, is not an an option for me. Thanks in advance for any advice you may have to offer.


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

Good idea, Doron, and something I thought to do at one point, but then got into a feverish “why the hell isn’t this working like it should?” loop.

Done. Installed as an upper on a modem. Worked beautifully. All ioctrl calls for the modem setup and status were captured. Typed “ATT”, and was able to capture the requests for all three characters and the , and get the “OK” response back.

IRPTracker shows the requests moving through my filter, through the device, and through another filter under the device. My filter code is doing what its supposed to do. The right requests are going to the right queues. Its receiving requests and forwarding correctly. A bit of a relief.

It must be a misconfiguration, or its something peculiar to setting a filter on top of ACPIEC. Thing is, I’m installing the registry entry the same way - just a different device. If you’re going to filter ACPIEC, where exactly should the UpperFilters entry be?

My filter and the wdf coinstaller are set for boot load.

I think your filter is in the right spot. I would now set a wdm preprocess routine for irp_mj_pnp/irp_mn_query_interface and log which guids flow through the stack and cross correlate that with what is in wdk headers

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: xxxxx@base2engineering.com
Sent: Friday, February 20, 2009 5:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Filtering ACPIEC

Good idea, Doron, and something I thought to do at one point, but then got into a feverish “why the hell isn’t this working like it should?” loop.

Done. Installed as an upper on a modem. Worked beautifully. All ioctrl calls for the modem setup and status were captured. Typed “ATT”, and was able to capture the requests for all three characters and the , and get the “OK” response back.

IRPTracker shows the requests moving through my filter, through the device, and through another filter under the device. My filter code is doing what its supposed to do. The right requests are going to the right queues. Its receiving requests and forwarding correctly. A bit of a relief.

It must be a misconfiguration, or its something peculiar to setting a filter on top of ACPIEC. Thing is, I’m installing the registry entry the same way - just a different device. If you’re going to filter ACPIEC, where exactly should the UpperFilters entry be?

My filter and the wdf coinstaller are set for boot load.


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