VisualKernel allows customizing various aspects of kernel debugging through the Debug Settings page in the VisualKernel Project Properties dialog. This page provides detailed description of those settings:
Below is the list of settings with the detailed explanation for each one.
Create a list of loaded modules when starting debugging
This setting controls whether VisualKernel will try to get a list of all loaded kernel modules each time it starts the debug session.
- If this option is enabled, you will be able to see the list of all modules via Debug->Windows->Modules command in Visual Studio. You will also be able to load symbols for the modules. However, making the initial module list may take a long time on slow connections.
- If you disable this option to speedup debugging startup, the list of all modules will not be available. Only the modules loaded during the debugging session (but not before it was started) will be debuggable.
Automatically load/unload module symbols
Linux kernel does not provide a common mechanism of tracking module load events by a debugger. VisualKernel works around this by setting special breakpoints and loading the modules automatically. However if you are using a heavily modified kernel with different structure layout, this may not work.
- Keep this option enabled for normal debugging.
- If you are using a heavily modified kernel, disable this option and load symbols manually using add-symbol-file.
Display kernel output by hooking the printk() function
Kernel modules can print diagnostic messages by calling the printk() function. This messages will end up in the system log and can be viewed by the dmesg command. VisualKernel can also display them in real time by hooking the mechanism used by the printk() function. However this can slow down debugging on slow connections.
- Disable this feature if you experience debugging slowdowns when seeing lots of printk() output.
Build/install a custom kernel module for collecting module information faster
The normal process of querying kernel module information (e.g. load address/section list) takes a lot of time because it involves following a linked list of module objects. This option allows speeding this process significantly by building and installing kernel module that maintains an additional list of modules in a more debugger-friendly format.
- Keep this option enabled for optimal debugging performance
- Disable this option if your module symbols are not loading properly
Debug a crashed/hanging system
Normally VisualKernel will connect to your target machine using SSH to deploy/load the kernel module. However if the target system has already crashed, the SSH connection won’t be available and VisualKernel will stop with an error. Use this option to override this behavior and disable any attempts of reaching the target machine over SSH.
Auto load symbols for main module
Normally VisualKernel will automatically issue the add-symbol-file/remove-symbol-file commands when the main module is loaded or unloaded. This provides seamless debugging experience just like with normal user-mode apps. You can use this option to disable this behavior if you want to load/unload the symbols manually.
Symbols for in-tree modules
Loading symbols for each of the numerous loaded kernel modules would take a lot of time and won’t be useful unless you are interested in debugging one of those modules. So by default VisualKernel won’t load any symbols for in-tree kernel modules. You can override this behavior using this setting.
- If you are interested in debugging a particular in-tree module, select it in the list here
- If you are analyzing crashed caused by an unknown module enable loading symbols for all modules
- If you are interested in debugging your main driver only, keep the default setting
Additional module symbol files
If your Linux system is running some custom modules that are not built with VisualKernel and are not a part of the kernel source tree, you can specify them in this setting so that VisualKernel will automatically load symbols for those modules.