Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is there a way to see BIOS interrupts that raises to Windows? Can I use "debug" (cmd command) to send interrupts to BIOS and trace some results?

share|improve this question
up vote 2 down vote accepted

Hardware interrupts

Someone seems to have told you that Windows NT runs on top of the BIOS, from which you've deduced that interrupts are fielded by the BIOS which then "raises to Windows".

That's completely wrong, and an erroneous model of how the operating system works. Aside from ACPI, system management mode, and (for some display adapters) VESA support, your BIOS firmware is largely uninvolved in anything once Windows is up and running. Interrupts (SMM aside) aren't fielded by the BIOS. They are fielded by Windows' Hardware Abstraction Layer, which does all of the low-level jiggery pokery with APICs, IDTs, and interrupt vectors necessary for fielding interrupts and handing them over to the Windows kernel.

To trace the handling of interrupt signals in Windows NT, one needs a debug kernel, communicating with a kernel debugger utility. Then one can do things with debugger commands such as !idt, !apic, and so forth.

Interrupt instructions

To call functions in the BIOS firmware API — which are (mainly, but not universally) invoked with the int instruction, and are thus confusingly also "interrupts sent to the BIOS" — and trace through their execution, you need DOS (or some other 16-bit real mode operating system). In particular you need a DOS debugging tool. You can run this tool either on a real DOS, such as OpenDOS or FreeDOS, or in a virtualized DOS machine, such as NTVDM on Windows NT. Be aware that the latter virtual DOS machine will affect firmware functionality.

You cannot invoke BIOS firmware API functions — which expect the processor to (variously) be in 16-bit real mode, 16-bit v8086 protected mode, or 16-bit ring 0 protected mode — in 32-bit ring 3 protected mode. The machine code simply won't execute correctly, even if you had a way to map it into virtual memory. Such firmware functionality is simply inaccessible from application mode on operating systems like Windows NT or Linux. (It's not really useful to applications on such operating systems, anyway.)

share|improve this answer

You can probably accomplish this, after all, there are constant interrupts passing through BIOS, I believe - events like keyboard input, disk io, basically everything. So, I'm going to say "Yes, there is A way".

As for discovering a way.. There's a community that managed their own open source bios firmwares coreboot. I suggest reading their developer documentation and possibly finding some of their devs on IRC and talking with them.

Do you strictly need to do this from within Windows? If you're only interested in BIOS, you may have better luck exploring this using Linux utilities. But that's beyond my present experiences.

Good luck.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .