Win7 IOCTL_ACPI_EVAL_METHOD Failure

Folks,

This is a question about ACPI driver differences between Windows 8 and Windows 7. An OEM has equipped our ACPI-enumerated device with an ACPI method to be turning on a certain bit in hardware on occasion. It’s been working fine on Windows 8: the driver is shipping now. They have now asked provide the same driver for Windows 7. Unluckily, an attempt to execute the same method there fails with the STATUS_ACPI_FATAL. This is basically the same driver installed onto the same device node running against the same ACPI BIOS: we are just booting off the Win7 drive on the same platform. I’m supplying the same ACPI_EVAL_INPUT_BUFFER, of course. The only difference is Windows 7 and its acpi.sys. OEM says it’s our fault, of course. :slight_smile: What could be wrong?

Many thanks,

Ilya Faenson
Rockville MD USA

Try a checked build and !amli. It’s worth validating that the system firmware shows the control method in question on both win7 and win8, the ACPI tables can be dynamically changed across OS versions.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, January 10, 2013 8:59 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Win7 IOCTL_ACPI_EVAL_METHOD Failure

Folks,

This is a question about ACPI driver differences between Windows 8 and Windows 7. An OEM has equipped our ACPI-enumerated device with an ACPI method to be turning on a certain bit in hardware on occasion. It’s been working fine on Windows 8: the driver is shipping now. They have now asked provide the same driver for Windows 7. Unluckily, an attempt to execute the same method there fails with the STATUS_ACPI_FATAL. This is basically the same driver installed onto the same device node running against the same ACPI BIOS: we are just booting off the Win7 drive on the same platform. I’m supplying the same ACPI_EVAL_INPUT_BUFFER, of course. The only difference is Windows 7 and its acpi.sys. OEM says it’s our fault, of course. :slight_smile: What could be wrong?

Many thanks,

Ilya Faenson
Rockville MD USA


NTDEV is sponsored by OSR

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

Appreciate the insights, Doron, I hoped you would chime in. :slight_smile:

What specifically should I be looking for? I know that the method is there as I was getting other error codes when the BIOS did not have it at all or when it was exposed to a different device node.

Many thanks,

Ilya Faenson
Rockville MD USA

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@microsoft.com
Sent: Thursday, January 10, 2013 5:23 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: Win7 IOCTL_ACPI_EVAL_METHOD Failure

Try a checked build and !amli. It’s worth validating that the system firmware
shows the control method in question on both win7 and win8, the ACPI tables can
be dynamically changed across OS versions.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Thursday, January 10, 2013 8:59 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Win7 IOCTL_ACPI_EVAL_METHOD Failure

Folks,

This is a question about ACPI driver differences between Windows 8 and Windows
7. An OEM has equipped our ACPI-enumerated device with an ACPI method to be
turning on a certain bit in hardware on occasion. It’s been working fine on
Windows 8: the driver is shipping now. They have now asked provide the same
driver for Windows 7. Unluckily, an attempt to execute the same method there
fails with the STATUS_ACPI_FATAL. This is basically the same driver installed
onto the same device node running against the same ACPI BIOS: we are just
booting off the Win7 drive on the same platform. I’m supplying the same
ACPI_EVAL_INPUT_BUFFER, of course. The only difference is Windows 7 and its
acpi.sys. OEM says it’s our fault, of course. :slight_smile: What could be wrong?

Many thanks,

Ilya Faenson
Rockville MD USA

You were getting this different error code on WINDOWS 7?

Go ahead and dump the method and see if it takes the same arguments and does what you expect. If you can’t think of any other way to dump it, there’s always the infamous ReadWriteEverything program.

Then, if you use the debug version of ACPI.SYS (which I believe is required) walk into the method to determine where it’s failing. I don’t recall the details off hand, because I haven’t done it for over a year now, but it’s really not hard.

Hope that helps,

Peter
OSR

Good point, Peter: I was indeed having non-“fatal” error codes returned on Windows 8 only at the time the original driver was being developed.

Good idea on RWEverything as well: I’ve used it before but did not think of it in this context until you’d mentioned it.

Rather helpful, thanks!

Ilya Faenson
Rockville MD USA

Reporting for the record what the issue was. That ACPI method was being called right in the context of the ACPI notification. Worked fine on Windows 8. Started working fine on Windows 7 too once I’ve delegated the execution to another thread. One apparently can’t call (some) ACPI methods out of (some) ACPI notifications on Windows 7. Note that the ACPI notification was called at Passive IRQL so this was not an execution level issue.

Thanks again to Doron and Peter for the prompt help,

Ilya Faenson
Rockville MD USA

I can confirm that I have *definitely* seen this as well. Made me nuts. Started working when I moved the method invocation from a notification to its own thread. I never investigated further.

Glad all is now well,

Peter
OSR