This adds an initial level of support for kernel mode targets to the symbol builder sample. As support for this required fixes in the debugger engine itself, using this functionality requires a "recent" debugger release (e.g.: May 2023 or later).
The main limitation of the support right now is that this will only work for KERNEL MODE MODULES in a kernel mode target. You cannot yet use the symbol builder to add symbols to user mode modules while kernel debugging. The module enumeration "redirector services" which are in the debugger engine only expose kernel mode modules because of the "impedance mismatch" between the way the debugger has classically worked (e.g.: the user mode modules list isn't fetched until an explicit gesture from the user such as a .reload /user, etc...) and the way the target composition APIs work (you can call for arbitrary processes). This MAY be resolved in the future.
Changes here include:
Tracking and plumbing through the "default address context" of the kernel in order to access kernel data (e.g.: for memory reads)
Not tracking individual processes for a kernel mode target
This adds an initial level of support for kernel mode targets to the symbol builder sample. As support for this required fixes in the debugger engine itself, using this functionality requires a "recent" debugger release (e.g.: May 2023 or later).
The main limitation of the support right now is that this will only work for KERNEL MODE MODULES in a kernel mode target. You cannot yet use the symbol builder to add symbols to user mode modules while kernel debugging. The module enumeration "redirector services" which are in the debugger engine only expose kernel mode modules because of the "impedance mismatch" between the way the debugger has classically worked (e.g.: the user mode modules list isn't fetched until an explicit gesture from the user such as a .reload /user, etc...) and the way the target composition APIs work (you can call for arbitrary processes). This MAY be resolved in the future.
Changes here include: