Windows 10 has a function to walk the pages using an enumeration index (MiWalkPage-something), but as Peter stated, everything about paging tables on Windows is internal and non-documented/non-exported. (Normal) kernel drivers should never mess with the page tables. If you still want to mess with it... you would have to lock the process's address space and do tons of shenanigans, OR build an hypervisor.

Before you go further down this path, I want to emphasize a couple of things.

1. The device extension in the DEVICE_OBJECT is cleaned up automatically when the device is unloaded. If you do your own, you become responsible for freeing that memory.
2. It takes the same number of lines of code to use placement new to construct your object in the device extension's memory as it does to construct the object using operator new. Actually, it takes fewer lines, because you have to provide your own "operator new".
3. The BEST answer is to write your driver with KMDF. The framework handles all of this for you, along with thousands of other details.

Technically, yes, how the DeviceExtension is allocated is an internal implementation detail. That is separate from the extension being private to the driver and the io manager ignoring the value of the pointer.

> I want to create a class object which represents my device...

Use "in-place new" if you are using C++, or cast the returned pointer to the desired type if you are using C.

Phil B
Not speaking for LogRhythm

The device extension is allocated with the device object, it is not allocated from a lookaside list separate from the device object. You can change the DeviceExtension value after the IoCreateDevice, the io manager doesn’t care what the value is.

Phil has the right answer. This is a very common idiom, going clear back to the streaming capture driver samples in 1999. Device Manager allocates the memory for you. You run "placement new" to run your constructor on that memory. When the device unloads, the memory is freed. Your destructor will not run.

     CDeviceExtension * devCtx = new (devobj->DeviceExtension) CDeviceExtension;

Of course, the better answer is to write the driver in KMDF, which handles all of this for you.

Suddenly (well, not suddenly -- I haven't checked in many weeks), I cannot get a response from any timestamp servers. verisign, globalsign, digicert -- none of them seem to work, either from Visual Studio or from a batch file calling signtool.

They all say
SignTool Error: The specified timestamp server either could not be reached or returned an invalid response.

Is it only me?

There do exist versions of STL that do not use exceptions, and those version do work in the kernel. That does mean they aren't standard-compliant, which brings up trust issues. I would never switch to a custom STL just to get support for tuples, which are easily implemented at structus.

On the other hand, if you look at the source, the Visual C++ version of tuple does not appear to throw any exceptions. If you were really desperate, you could probably isolate it yourself.

Templates are a compiler feature, and the MSVC for kernel drivers supports it.
You can simply do a template <typename T1, typename T2> struct Tuple { T1 v1; T2 v2; }; if you really need something that looks like a tuple... althought you don't need tuples in any way...

You're writing a driver for an operating system, you're sort of a "part" of the OS. You're the one providing feature to the softwares running in usermode (or even other drivers, for that matter). You should be able to write a kernel component/driver without needing any libraries or extensions. So please.

Could this means that C++ templates in the kernel cannot be used? or in very limited circumstances?

What makes you think that templates and exceptions are related in any way?