I have posted an update to VMKD VMKD (1.1.1.7). Since the last release (1.1.1.4), the following things have changed (there is a changelog included with the package):
- Fixed an assert that kdvmware.sys was tripping on checked builds of the kernel (whoops). There was a bug in the code that was reprotecting kdcom.dll as a part of assuming control over the KD I/O routines.
- Added a potential fix for occasional difficulties resynchronizing with the guest across a reboot if DbgEng is not restarted. If you are still seeing synchronization problems from time to time, I’d be interested to see debug output from vmxpatch (available by attaching a debugger to vmware-vmx.exe) and DbgEng itself (available with CTRL-D/CTRL-ALT-D in kd.exe or WinDbg.exe, respectively).
- Added support for partial checked builds in a rather limited fashion. Any checked kernel that is used with VMKD ought to be named “krnltest.exe” in the guest. This seemingly arbitrary limitation is present because the file name specified via /KERNEL= is the actual name that appears in the loaded module list, and VMKD uses string comparisons on loaded module list file names to find the kernel image in-memory. There are certainly “better” ways to do this, but the current approach is fairly simple and aside from checked builds, tends to be the most reliable and officially supported way across a wide range of OS versions. Any file name may be specified for the checked HAL module in a partial checked build configuration.
In the future, I may update the check to be more clever about finding the kernel so as to not rely on string comparisons, but it does not really appear to be worth the time for most purposes at this point.
Additionally, it has been confirmed that VMKD works with VMware Server 1.0.4 (no changes were required on VMKD’s end, and previous releases will work with VMware Server 1.0.4 as well). I still have not gotten around to verifying the operation on VMware Workstation, as for most purposes I have moved my VMware usage almost completely over to VMware Server.
Now, back to your regularly scheduled coverage on the depths of thread local storage on Windows…
Isnt the kernel always the first entry in PsLoadedModuleList? Not saying its correct but ive seen production code using ZwQuerySystemInofrmation with a buffer that fits exactly one module entry and it uses that as the kernel base address, regardless of the image name (which is different for PAE/SMP systems). Even if its not 100% correct perhaps thats adequate to assume this for VMKD or is this not the case on checked builds?
I’d prefer to avoid making those kinds of assumptions if possible. What I’d probably do if I wanted to remove the filename comparison is resolve the address of a symbol (such as an exported API) that I know to be within the confines of the kernel, and then from there search for a module in the loaded module list that contains the API within the confines of its image space.
[ebp+4] should do the trick in your driver entry if thats what you wanted to do…