I am trying to run one of the minifilter samples from Microsoft provided here: https://github.com/Microsoft/Windows-driver-samples/tree/master/filesys/miniFilter/passThrough
I don't know what this minifilter is supposed to do (documentation isn't great), but for starters, if I can just see the output from a DbgPrint() statement, I'll be happy. While running Sysinternals DebugView as admin, I did fltmc load passthrough and fltmc unload passthrough, but did not see any output from the filter. I know that at least the function corresponding to the unload feature in the code has a DbgPrint() message:
PT_DBG_PRINT( PTDBG_TRACE_ROUTINES,
("PassThrough!PtUnload: Entered\n") );
Am I supposed to see these messages? If so, how? If not, how can I debug minifilter development?
PS: I did define the Registry key suggested here: https://www.danclarke.com/debugview
You can do it from the debugger attached using the:
ed nt!Kd_DEFAULT_Mask 0x8
Or check this link out as you can also enable it from the registry.
Make sure you've enabled 'Capture Kernel' under the Capture drop-down menu, instead of 'Capture Global Win32' which is what the article you linked us to mentions.
As for the File-System Mini-Filter device driver sample you linked us to, there's plenty of documentation surrounding development of filter-manager drivers available over at MSDN.
If you go into driver development blind with the Microsoft samples, you can't really expect to understand how it all works with a click of a finger... It is very different to user-mode development, you'll be starting from the bottom again.
Look at PT_DBG_PRINT macros in the source code:
#define PT_DBG_PRINT( _dbgLevel, _string ) \
(FlagOn(gTraceFlags,(_dbgLevel)) ? \
DbgPrint _string : \
((int)0))
There is a condition that checks gTraceFlags variable. By default gTraceFlags is 0. So just set that variable to enable DbgPrint, for example:
ULONG gTraceFlags = PTDBG_TRACE_ROUTINES;
Related
I am new to kernel mode windows driver development and having issues getting debug information out of the WFP callout samples. I am looking for either more options or tips of what I am doing wrong with the options I have been trying.
To start with I downloaded the WFP sampler and followed the instructions in it's description. I am using a Windows 8.1 x64 host and a Windows 7 x64 target connected via a simulated serial cable. They are both VirtualBox VMs.
The primary command I am debugging with is
WFPSampler.Exe -s PROXY -l FWPM_LAYER_ALE_BIND_REDIRECT_V4 -aaid "C:\Program Files (x86)\Internet Explorer\iexplore.exe" -pla 10.0.2.15 -v
Where 10.0.2.15 is the IP address of a diffrent network interface than the routing table is endign traffic to. I also used the following inspect command as recommended by the instructions:
WFPSampler.exe -s BASIC_PACKET_EXAMINATION -l FWPM_LAYER_INBOUND_IPPACKET_V4 -v
"netsh wfp show state" shows the callout and filter associated with the expected layer
However I never got any messages from traceview as per the last steps of those instructions. Tracelog had similar lack of output. This was true with or without WPP tracing enabled on the driver project. I also tried higher verbosity, all to no effect.
Additionally the remote debugger in visual studio either stopped at "Driver Post Install Actions (x64) (possible reboot): Pass" or "Waiting to reconnect..." rebooting the target did not cause more output in the Debugger Immediate Window (the Output window never got any output). Rebooting the target VM did not get any unusual prompts (some things I read implied it should). The reconnect checkbox when setting up the debugger sometimes caused it to get past the "Waiting to reconnect..." prompt, other times it was not needed. I set a number of breakpoints that should have been hit including one at the top of every classify function and none were ever hit.
I tried to debug with WinDbg, but well, frankly I can't find the documentation about how to use this tool. I start it on the target machine and chose kernel debug, local. then I get a prompt that tells me the symbol search path is invalid and no clue what I am supposed to set it to. Any documentation on how to use this tool as opposed to just installing it may be helpful if it lets me debug these callout drivers.
Finally of course I tried just debugging it based on symptoms and I find that the examination callout does nothing as far as I can tell, while the proxy callout just eats all traffic from the targeted application, with one caveat. That caveat is that when I target firefox or chrome with the proxy callout and try to launch that app it fails to launch a UI and the partially started process cannot be killed from task manager.
I assumed that behavior may be the result of the sample failing to check FwpsQueryPacketInjectionState but modifying as best I can figure out that should be used does not seem to change the behavior.
So in short I am stuck and need direction please?
I started experimenting with the WFPSampler and also discovered that tracing didn't work. Oddly enough, there was a lot of additional code to make WPP tracing work on multiple OS's, but the sample doesn’t capture any trace events. So I debugged it and found the call to the nt!WmiTraceMessage always passed 2 as the TRACE_HANDLE. This seemed bad. Safe it to say, this wasn't exactly straight forward to unscramble WPP macros and then finally find the origin in the .vcxprog file. The definition of WPP_COMPID_LEVEL_LOGGER(COMPID,LEVEL)=2 is incorrect. While I was there, I also converted the DbgPrintEx Levels to match Tace_Level by adding 2 so Error/Warning match the model.
Complete the following steps for SysLib/WFPSampler and Sys/WFPSamplerCalloutDriver
Open the Project
Right Click on WFPSamplerCalloutDriver
Unload Project
Right Cick on WFPSamplerCalloutDriver
Edit WFPSamplerCalloutDriver.vcxproj
Type: WppPreprpocessorDefinitions
Change this definition in both places in the file:
To:
<WppTraceFunction>DbgPrintEx(COMPID,LEVEL,MSG,...)</WppTraceFunction
<WppPreprocessorDefinitions>WPP_COMPID_LEVEL_LOGGER(COMPID,lvl)=(WPP_CONTROL(0).Logger),;WPP_COMPID_LEVEL_ENABLED(COMPID,lvl)=(WPP_CONTROL(0).Level >= lvl+2)</WppPreprocessorDefinitions>
Save the File
Right Cick on WFPSamplerCalloutDriver
Click Reload Project
Rebuild
I believe if you adopt this model of using DbgPrintEx as your trace function, you can switch to WPP without editing the entire project. However, I still think it's better to just convert in your program.
Cheers,
John
Not exactly an answer to this question, I never got a debugger working, but an explanation of why the wfpsampler sample didn't work for proxying by ALE layers. The end goal of this project.
In the Proxy callout there were these lines (i think before my refactor they were in the PerformProxySocketRedirection method):
if (ipProtocol == IPPROTO_TCP)
pBindRequest1->portReservationToken = (pRedirectData)->pProxyData->tcpPortReservationToken;
else if (ipProtocol == IPPROTO_UDP)
pBindRequest1->portReservationToken = (pRedirectData)->pProxyData->udpPortReservationToken;
udpPortReservationToken or tcpPortReservationToken should have been initialized by a call to CreatePersistentUdpPortReservation or CreatePersistentTcpPortReservation and this is handled in a helper function named HlprWinSockCreatePortReservation, but said helper function is never called, from anywhere in the entire solution. Those fields are never set, anywhere, ever.
Additionaly, that value only needed set if the local port was being changed, but that block of code executed regardless.
remove these lines, and so long as you don't change the local port, the ale redirect sample works as you would expect including changing the outgoing interface if you change the local IP. If you do need to change the local port, you will have to use HlprWinSockCreatePortReservation to initialize the appropriate port reservation token variable in the PROXY_DATA. This must be done in user mode, so you need to do it in the service when setting up the filter.
Disclaimer: I think that is the only important change, but if you are here for a solution to this problem know that while tracking this down without a working debugger i changed a ridiculously large amount of code so there may have been more to it I forgot over the course of the last few weeks. But I did go back and verify that that block was always called and those fields were never set in the original.
Is there any default mechanism to enable debugging the v4l2 drivers.
Basically I want to check something like dynamic debugging by setting in /d.
Compile time flags in make file also fine.
Currently, I had set as below, however not getting much information.
echo -n 0xFFFF>/sys/module/videobuf2_core/parameters/debug
Can anybody help me to get verbose v4l2 logs?
Have a look in the code: As an example the file
drivers/media/v4l2-core/v4l2-ioctl.c
might be one of the more interesting ones, cause it shows you some of the user/kernel-space interactions.
In this file you see a lot of pr_cont, pr_info and others. While printk is always printed, the others only do something, if enabled. All details on this can be found on http://lwn.net/Articles/487437/ .
The nasty way is to just replace some of the pr_cont or pr_info by printk. You can even use a #define to do this. If you only want to enable 3 or 4 of them and even add your own special ones, this might be the fastest way.
The nice way would be to have a look on how the system is thought to be used. You can try if you can enable dynamic debugging, like it is nicely described here https://lwn.net/Articles/434833/ .
Finally the easiest way might be to have a look in the kernel config. Perhaps you already know the command make menuconfig in the source directory.
You can edit all the different settings, and like in vi, you can search using /.
Next to the specific modules, you can usually also enable or disable debugging options.
If that's not enough, you can always change the global debugging level of the kernel in the .config file.
One specific flag you might be interested in is
CONFIG_VIDEO_ADV_DEBUG
Say Y here to enable advanced debugging functionality on some
V4L devices.
In doubt, say N.
Symbol: VIDEO_ADV_DEBUG [=y]
Prompt: Enable advanced debug functionality on V4L2 drivers
Location:
-> Device Drivers
-> Multimedia support (MEDIA_SUPPORT [=y])
Defined at drivers/media/v4l2-core/Kconfig:11
Depends on: MEDIA_SUPPORT [=y]
good luck
Please refer to the official documentation here:
The ‘dev_debug’ attribute that is created for each video, vbi, radio
or swradio device in /sys/class/video4linux// allows you to
enable logging of file operations.
I tested this on real configuration and it works(it prints all info!), see my command below:
echo 0x1f > /sys/class/video4linux/video1/dev_debug
I need to capture the DeviceIoControl() system calls of an application. On linux, strace can be used to analyze all ioctl calls. Is there any similar functionality on windows?
MSDN website recommends a program called "Process Monitor" to analyze the real-time activities of executables. However, "Process Monitor" does not show anything about DeviceIoControl calls.
Have you tried OSR's IRPTracker?
IrpTracker allows you to monitor all I/O request packets (IRPs) on a system without the use of any filter drivers and with no references to any device objects, leaving the PnP system entirely undisturbed. In addition to being able to see the path the IRP takes down the driver stack and its ultimate completion status, a detailed view is available that allows you to see the entire contents of static portion of the IRP and an interpreted view of the current and previous stack locations.
To capture the DeviceIoControl() function you can use an API hook. My company provides Deviare, a hook engine with a high level interface. You don't need to know a lot about hooking it can be used freely (just display a dialog saying unregistered version). It includes a hook console with source code.
Recently discovered Rohitab's API Monitor
It hasn't been updated for 2 years, but it does work on my Win7 x64. It has very good API filtering capabilities.
The Dr. Memory (http://drmemory.org) tool comes with a system call tracing tool called drstrace that lists all system calls made by a target application, including NtDeviceIoControlFile, along with their arguments: http://drmemory.org/strace_for_windows.html
I'm getting no debug information when debugging en_windows_7_checked_build_dvd_x86_398742.
I can't see even my own trace info (ATLTRACE).
In opposite, Windows XP Checked works like a charm.
I get "Bad QueryIdType:5" msg on debug session start with Windows 7.
Kernel debug is set up properly obviously.
Please help...
I was able to fix it from within windbg, on windows 7 32 bit:
ed Kd_DEFAULT_Mask 8
According to the msdn article, you can also use the registry, but you must reboot for it to take effect. Create a DWORD key under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter called DEFAULT with a value of 8.
The up to date microsoft documentation is available here: http://msdn.microsoft.com/en-us/library/windows/hardware/ff551519(v=vs.85).aspx
OK, i found the solution here. It may help people:
The problem: Your DbgPrint or KdPrint messages don't appear in WinDbg (or KD) when you run your driver on Windows Vista.
The reason? Vista automatically maps DbgPrint and friends to DbgPrintEx. Now, you may recall that DbgPrintEx allows you to control the conditions under which messages will be sent to the kernel debugger by filtering messages via a component name and level in the function call and an associated filter mask in either the registry or in memory.
In Vista, DbgPrint and KdPrint are mapped to component "DPFLTR_DEFAULT_ID" and level "DPFLTR_INFO_LEVEL". Of course, in Vista, xxx_INFO_LEVEL output is disabled by default. So, by default, your DbgPrint/KdPrint doesn't get sent to the kernel debugger.
How to fix it? Two choices:
Enable output of DbgPrint/KdPrint messages by default --Open the key HKLM\SYSTEM\CurrentControlSet\Session Manager\Debug Print Filter. Under this key, create a value with the name DEFAULT Set the value of this key equal to the DWORD value 8 to enable xxx_INFO_LEVEL output as well as xxx_ERROR_LEVEL output. Or try setting the mask to 0xF so you get all output. You must reboot for these changes to take effect.
Specifically change the component filter mast for DPFLTR. In early releases of Vista/LH you changed the default printout mask by specifying a mask value for the DWORD at Kd_DPFLTR_MASK ("ed Kd_DPFLTR_MASK"). In build 5308 (the February CTP of Vista), it seems that the mask variable has changed and you need to set the mask value for the DWORD at Kd_DEFAULT_MASK ("ed Kd_DEFAULT_MASK). In either case, specify 8 to enable DPFLTR_INFO_LEVEL output in addition to DPFLTR_ERROR_LEVEL output, or 0xF to get all levels of output.
See the WDK documentation for Reading and Filtering Debugging Messages (follow the path: Driver Development Tools\Tools for Debugging Drivers\Using Debugging Code in a Driver\Debugging Code Overview) for the complete details on the use of DbgPrintEx/KdPrintEx. Or look at the Debugging Tools For Windows documentation (Appendix A) on DbgPrintEx.
For enabling output of DbgPrint/KdPrint messages by default the registry path is "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter"
Session Manger ist below Control. The Default value normaly is 0xf. That enables all messages.
To set a better fitting bitmask at your needs the informations are located at
https://learn.microsoft.com/de-de/windows-hardware/drivers/devtest/reading-and-filtering-debugging-messages#identifying-the-component-name
If you take Visual Studio 2015 or 2017, the standard configuration won't set this flag by default. When start working with examples don't forget to set this extra on the Debug-Target.
So this helped me in my Windows 10 environment using Windbg.
A second problem was using devcon on Windows 10 like described in the echo example
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debug-universal-drivers---step-by-step-lab--echo-kernel-mode-#install
At Bullet "7 Locate the built driver files" transfering the needed driver files to the Debug-Target and load them with devcon. Using Windows 10 you also have to copy the catalog-File. Otherwise devcon.exe will fail as described.
Of cause you will need to install the test-certificate as well. This is usually done when preparing the debugging environment with Visual Studio 2015/2017. Just double check with certmgr.
What is the best way to debug a custom ODBC driver on Windows? A former member of our team wrote the driver so we have the source available.
How do you attach a debugger to the driver? Or is it easier to just add "trace prints" to the driver to see what is going on?
The best solution i found so far is a combination of trace prints and breakpoints (int 3) compiled into the driver.
Trace prints for general debug information and the breakpoints for pieces of the code where I need to more thoroughly investigate the inner state of the driver.
You can debug any ODBC driver by activating the logging for it via the Control Panel.
Just go to driver's properties, activate the logging and set the target log file - and then set up another program to read from it interactively, so you can see what's going on.
As far as I know, ODBC drivers are just DLL's which implement a specific set of functions. So if you have the sources available, you can use Visual Studio to debug it. Here is an article which seems to be something in the right directions: Debugging DLL Projects in Visual Studio 2005.
Supportingly to VS you could use WireShark to see what the ODCB driver is sending to the DB.