Modifying Windows disk driver to use updated control codes like IOCTL_DISK_GET_DRIVE_GEOMETRY_EX

Question

I'm trying to modify a Windows kernel-level disk driver to properly respond to updated control codes. For example, it only had a handler for the obsoleted IOCTL_DISK_GET_DRIVE_GEOMETRY control code, but not the newer IOCTL_DISK_GET_DRIVE_GEOMETRY_EX control code, so I added that.
Of course, I updated the driver to use all the new Windows structures and functions too, like the IoReadPartitionTableEx() function and the DRIVE_LAYOUT_INFORMATION_EX structure (I am trying to add GPT support to the driver). The issue is, when I use the disk driver, I can see (using DebugView) that Windows (I think it's Windows... perhaps it's something else...) is still sending the old IOCTL_DISK_GET_DRIVE_GEOMETRYcontrol code to my driver. I would like Windows to send the newer control codes to my driver. Is it even Windows that is sending these control codes? Is there perhaps some other layer between Windows and the driver that I'm just not yet aware of?

Is the driver supposed to somehow identify its "type" to Windows, so that Windows knows exactly how to "speak" to it? How does Windows know exactly which control codes to send to a particular driver? I've Googled around for answers to these (seemingly very basic) questions, and haven't found a clear answer, which leads me to believe that I've fundamentally misunderstood something about Windows drivers here. Does my question even make sense?

Answer 1

The OP has 5 questions (count based on number of question marks). Each of the following answers the questions in the same order as they were asked in OP.

1. To find out who is calling your driver with IOCTL_DISK_GET_DRIVE_GEOMETRY put a breakpoint on the handler for that IOCTL in your driver. When break occurs then look at the callstack. You'll see who called.

2. You'll actually have a layered set of callers. This will answer your question about layers.

3. Windows knows about your drivers capabilities in several different ways. If you have a miniport driver, then there is a minimal set of functionality that each type of miniport must implement.

   In addition there are APIs to StorPort miniports can use to indicate optional capabilities. For example StorPortInitializePerfOpts is used to inform StorPort about various perf optimizations in StorPort miniports. To better answer this question please provide the type of driver that you have. In case you're not familiar with the various driver types, I suggest you read this from MS HW dev center. In fact you may want to read it anyway.

4. The question assumes Windows sends different control codes to different drivers based on some hypothetical driver attribute. However the model Windows uses is like that mentioned in the previous answer. There are base capabilities based on the driver model and then in some cases APIs to communicate capabilities. (In other cases it is up to the driver to indicate it doesn't support a particular operation.)

   There is another aspect to the answer and that is Windows and non-Windows components are free to choose whatever control codes they want. So a 3rd party disk partitioning program could use the older geometry IOCTL, even though a newer one exists because it wants to be compatible with earlier versions of Windows. Or a Windows component (eg Storage Spaces) could use a newer IOCTL because it doesn't carry about backwards compatibility.

5. (This question is asking for an opinion, so this answer is my opinion). Assuming by "question" you mean "questions", then I'd say more or less. But if this is your first (or second) foray into Windows drivers, I again suggest reading the relevant MS documentation (linked above).

Finally, even though the OP doesn't ask directly, it sounds like there is a question "How do I test the IOCTL_DISK_GET_DRIVE_GEOMETRY_EX functionality I've added?". The simplest way, IMO, is to write a Win32 test program. To invoke and display this one IOCTL would only take 20 or so lines of code. Which would be easier and quicker then, say, scripting DISKPART or similar.