Writing a kernel driver to access physical memory under windows 7 and windows 8.1

Hi there. Have done my full text search, but still don’t know what to begin.

Have to apologize, first, my bad English, second, I am pretty much a newbie in windows driver world, I self learned windows kernel driver for about 2 months, if I do or say something wrong, I am sorry.

As a BIOS engineer, I am always troubled with the lacking of OS side observation / debugging tools, WinDBG is nice, but sometimes debugging a small issue using a checked ACPI.sys is really not that cost efficient, and sometimes doesn’t that handy if I’m in a field debug or an on-site debugging process.

Also, BIOS code nowadays has some specific WMI / customized ACPI method, evaluating them is always hard.

I also use “RW everything” to debug, but it is not flexible enough. I begin to think about writing my own tooling, and I’m also very interested in building wheels, see how things work.

I make a list for my tooling, most of my problems are on the kernel (ring0) driver side, which the problems are:

  1. Access physical memory, for modifying GPIOs / IO ports / PCIe registers on the fly which are usually memory mapped these days.

  2. Be able to evaluate customized ACPI method / events / WMI interfaces, e.g. To debug an ACPI method just by giving the method name and arguments, or evaluate EC _Q event on the fly, just feed the needed arguments. I don’t have any idea now, from BIOS perspective, we usually using find RSDT pointer first, then find other ACPI tables, which, needs physical memory access, too. And I usually debug ACPI using “ACPINVS memory debug” method, which is, I would allocate a chunk of ACPI memory in some operation region in any ACPI table, then boot into windows, using RW everything or any memory viewing software to observe that particular memory address, then I’ll put my ACPI debug message there. (Which is pretty neat) I think my driver would have to be able to do the same thing, but smarter.

  3. Be able to access PCI IO and regular Port IO, such as EC or port 80 (I’ve completed this, relatively easy comparing to requirement 1 and 2…)

The most of my concern is, that I knew physical memory access is pretty much “illegal” from OS perspective, but it is sometimes the only way to probe BIOS functions. Is there a safe way or a safer mechanism to access physical memory?

Second, any suggestion for me to study on? I’m now reading “Programming the Microsoft Windows Driver Model” and “Windows Internal 6th Edition”.

I know very well that I am now still to rookie to do the tasks above, but I’m still trying. Hats off for you guys, windows driver is really tough to learn.

Matthias wrote:

The most of my concern is, that I knew physical memory access is pretty much “illegal”
from OS perspective, but it is sometimes the only way to probe BIOS functions. Is there
a safe way or a safer mechanism to access physical memory?

You don’t really care about safety in an environment like the one you’re describing.

I would point out that most of what you’re asking can be accomplished with a windbg connection to the kernel debugger. Physical memory access and I/O port access are all available.

Years and years ago, we wrote a debugger that does basically what you’re describing, designed for the hardware lab. It was originally written for DOS using DPMI (remember that?), then extended for Win 95, then extended again for Win NT. We have one version with an embedded Forth interpreter and one with an embedded C interpreter, for scripting hardware tests. We haven’t touched in probably 10 years, but you can see it would help you. http://www.probo.com/debugger.php

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

Thanks Tim, after seeing the CDBG, I thnk I’ve written a same DOS tool using djgpp & DPMI, which is really good, but BIOS running in OSPM is a more different thing, most of the boot services will be destroyed when we transfer the control to OS, and most of the peripheral devices would have change their behaviour.

Now I’m sometimes using WinDBG to debug ACPI or WMI, but sometimes in development I don’t have the luxury to set up a WinDBG, e.g. I would have to develop with a reference board which has no USB / no ethernet, and UART will be occupied by other HW, something like that.

This is why I’m thinking about writing my own resource monitor-like software / driver, despite the fact that UAC would’ve made the whole debug process a pain in the butt, I still love to learn to develop it.