Running ACPI methods using !amli run

I’m new to the use of the AML debugger and the !amli extensions in WinDbg. I read the MSDN documentation on basic AML debugging and on the use of the extensions.

I can break into the debugger, step, and trace my ACPI methods. That much I figured out. Trace works better than I thought it would.

I discovered the “!amli run” command. The MSDN documentation says you use the command to run an ACPI method. I’ve attempted that using the method strings copied right from the source (e.g., !amli run _SB.PCI0.LPCB.EC0._Q2B). It returns blank when you hit enter at the command line. No error message, no “method completed” message, no nothing. Questions:

  1. Does this command allow you to run methods from the debugger command line? You can just pick any random method and run it?

  2. Will it tell you if it ran it successfully? Will it tell you if it had an error?

  3. The !amli debugger has four breakpoints defined. I don’t know what they are - I didn’t create them. They cannot be deleted. What are they?

  4. How does one capture a Notify? I’d like to capture a notification and break, or even just know that one occurred.

  5. Is it possible to read and write objects (e.g., fields by name, or named objects) from the command line? Can it be done by their ACPI names, or must it be done by host address?

Thanks for any guidance you may offer.

I think the issue is that ‘run’ is an ‘amli command,’ not an ‘amli extension’ which means that you
have to be at an amli debugger problem to use it. That is, while ‘!amli run’ does not work, if
you’ve entered the amli debugger already (by using ‘!amli debugger,’ for example), then all you do
is type ‘run’ (followed by the necessary argument(s).

Unfortunately, I don’t have presently have a target setup using a CHK build of acpi.sys, so I can’t
really confirm that.

Since you’re new to this, I’ll offer the opinion that this a very common issue with msft tools,
where they (imo) define pointlessly overly granular nomenclature that means squat to everyone else,
which they then go to use and document inconsistently, and for reasons that I simply do understand
they name everything the same way, so it all looks alike, and usually is similar, but never the
same, so it can all get incredibly confusing.

This is actually (imo) a particularly bad case:

There’s already the meaningless distinctions (in my opinion) of:

  1. Windbg commands
  2. Windbg metacommands
  3. Windbg extension commands

The last has a very clear meaning for anything that doesn’t come with windbg (i. e. - third party
provided), and internally at msft, there’s a very important difference between the first two and the
last one - the first two are part of ‘windbg’ proper and are provided and maintained by the windbg
team, but the later are not, which makes them more or less unsupported. The thing is, the rest of
us don’t and shouldn’t need to care whether something is a 1, 2 or 3, but the documentation (toc)
does, so I think it just adds needless confusion.

The AMLI distinction is defined in one place:

‘The AMLI Debugger supports two types of specialized commands: AMLI Debugger extensions and AMLI
Debugger commands.’

So:

  1. AMLI debugger extensions
  2. AMLI debugger commands

(4) is misleading in and of itself, and probably should read ‘AMLI debugger extension commands.’
Even them, it’s still inaccurate, in my opinion, because it implies that one could enter
‘!amli.help,’ for example, the same way that one could enter ‘!wdfkd.help,’ for example, but that
won’t work, because, as it happens, ‘amli’ isn’t an extension. It’s a single command provided by
the ‘kdexts’ extension, which is by default the first extension in the chain, and the one that
provides the normal ‘kernel debugging extension commands’ like ‘!irpfind,’ so it’s a shorthand for
‘!kdexts.amli.’ Unless, you’re on W2K or before, in which case it’s part of the 'acpikd’extension.

(5) is documented on one page in the windbg docs, and doesn’t appear to be easily searchible on line

  • i. e. - ‘!amli run’ doesn’t return anything obviously useful in google.

Finally, compounding all of this is that if you enter ‘!amli’ followed by an invalid ‘AMLI debugger
extension command,’ it doesn’t produce an error message, so that’s why you’re not seeing one for
‘run,’ which is what you’d see for ‘!amli xyz.’

I think that all of this is correct, but, frankly, I’ve been wrong on just about everything I’ve
done today, so maybe not.

Good luck,

mm

Good luck,

mm

xxxxx@base2engineering.com wrote:

I’m new to the use of the AML debugger and the !amli extensions in WinDbg. I read the MSDN documentation on basic AML debugging and on the use of the extensions.

I can break into the debugger, step, and trace my ACPI methods. That much I figured out. Trace works better than I thought it would.

I discovered the “!amli run” command. The MSDN documentation says you use the command to run an ACPI method. I’ve attempted that using the method strings copied right from the source (e.g., !amli run _SB.PCI0.LPCB.EC0._Q2B). It returns blank when you hit enter at the command line. No error message, no “method completed” message, no nothing. Questions:

  1. Does this command allow you to run methods from the debugger command line? You can just pick any random method and run it?

  2. Will it tell you if it ran it successfully? Will it tell you if it had an error?

  3. The !amli debugger has four breakpoints defined. I don’t know what they are - I didn’t create them. They cannot be deleted. What are they?

  4. How does one capture a Notify? I’d like to capture a notification and break, or even just know that one occurred.

  5. Is it possible to read and write objects (e.g., fields by name, or named objects) from the command line? Can it be done by their ACPI names, or must it be done by host address?

Thanks for any guidance you may offer.

If nothing else, your post was entertaining, thanks. I’ve had those kinds of days too.

Checked build of ACPI.sys runs well on an otherwise free build, by the way. It doesn’t require a full Checked setup.

I think the confusion is in actually getting ANY command to run at the AMLI debugger prompt. None of them were running after the first break into ACPI land. I entered another !amli debugger, hit “g”, and forced another ACPI event. It broke back into the AMIL debugger again, and now the commands (dns, lc, find, etc. - without the !amli prefix)) are running as they should. I ran something using “run”, and it did something - need to go figure out what.

The other frustrating part of the AMLI debugger is finding the right combination of flags that tells me when an ACPI methods was hit, but doesn’t trace every single line. With the right combination of glags, you can get single line notifications, like:

AMLI: 89b9a490: AsyncEvalObject(_SB.PCI0.LPCB.EC0._Q2B

Which are nce when you’re debugging you’re driver, and you want to see how the ACPI methods are working without tracing every single line of every single ACPI call.

Its not consistent. You’ll write the flags down, and then set them up that way, and it won’t work. You’ll break, change some flags, and run again, then break, change the flags back, and then it’ll work.

To follow up with an even simpler question, I want to manually read values in the namespace. I do a “dns” for a namespace object, for example:

AMLI(? for help)-> dns /s \P80H
dns /s \P80H

ACPI Name Space: \P80H (8a9884d8)
FieldUnit(P80H:FieldParent=8A988494,ByteOffset=0x0,StartBit=0x0,NumBits=32,FieldFlags=0x80000013)

It finds the object, and gives me what I believe to be the location in memory for that object. There are two addresses given above:

  1. 0x8A9884D8
  2. 0x 8A988494 + ByteOffset 0x00 = 0x8A988494

Doing a memory read (db) of either location fails to return the value I think should be there (that was just written via a Store instruction in the traced method. Tried it with the values given, and with a “%%” in front of it to translate to physical (returned all 0xFF, of course).

What I’m trying to do is manually read the location that was just Stored in the method. How do you do that while stepping through a method?

Let me ask this a simpler way.

ACPI has operating regions, and fields in those operating regions. The fields are used in methods that I am tracing.

How do I manually peek/poke those fields from within WinDbg? As an example:

AMLI(? for help)-> dns /s SB.PCI0.LPCB.EC0.GWSS
ACPI Name Space: SB.PCI0.LPCB.EC0
.GWSS (8a94ec6c)
FieldUnit(GWSS:FieldParent=8A94E928,ByteOffset=0x52,StartBit=0x0,NumBits=1,FieldFlags=0x80000011)

The dns return provides two addresses: 8a94ec6c, and 8A94E928 + 0x52. I don’t know what they are, but they are not the actual address of the field in memory.

I’m tracing method calls, and I want to see the actual fields being used in the method. I want to see them before an evaluation is done, and then check them after a Store.

Is this possible? It should be, because the fields are accessed during the method trace, and the trace provides the actual read/written value.

Please let me know. Thanks.