debugging minifilters - file

I have been writing and debugging a minifilter on Windows 7 using the IFS Kit for some time now. it finally works, but as I require to add further functionality, I will spend some more days playing with it
what I'm worried about is debugging. until now I have simply built the driver, installed it on a virtual box and tested it by verifying dbg_print statements. I have been using this simple and error prone approach, as I could not find anything about how to debug minifilters more structured and programmatically.
are there any best practice methods to debug minifilters or filters? can visualDDK be used to add (remote) debugging functionality to visual studio for minifilters?
greetings,
curiosity

The Windows DDK includes a copy of windbg which you can use to connect to the VM over a named pipe with the appropriate configuration.
You can do one better by using VirtualKD to get an accelerated channel to talk to the kernel debugger embedded in Windows.
If you want to do debugging using the Visual Studio user interface, you should look at VisualDDK.
Both are powerful tools, but they require a little work to get set up the first time.
I tend to just use WinDBG because it is the easiest thing to set up on random QA machines etc.
But I have used those tools to iterate rapidly during initial development of a project.
Good luck.

Visual Studio does not support debugging in kernel mode. You can use kd or WinDbg, which are both part of the Debugger package included in Windows DDK. This will get you started with debugging:
Configure kernel debugger on VM and attach WinDbg. Instructions are here: http://ndis.com/ndis-debugging/virtual/vmwaresetup.htm.
Build your binaries in debug mode (or in release with full symbols).
Once WinDbg connected, fix up symbols, and source path. Make sure you added location of symbols of your new driver to the symbol path.
Now you can debug similar how you use VS for user mode apps.

Related

Atmel Studio 7 doesn't show any debugging tools

I just installed Atmel Studio 7 on my Windows 10 HP laptop. This is my first time working w/ a C compiler since high school, and my first time working with a microcontroller.
I loaded one of their example projects and built it without any errors. However, I am not able to debug since there is no option for a debugging tool (see screenshot). The only option is for 'Custom programming tool', while their tutorial videos all show an option for a SAM-ICE debugger or Simulator (e.g. https://www.youtube.com/watch?v=9QlDSNeuAdY)
I have spent hours trying to find an issue online w/ no luck. Please help!
I have had the same problem. I solved this by unchecking the box Tools->Options->Debugger->Backend Agent-> Start Local Backend Agent and then checking that box again
I'll add this information as I also just spent a fair amount of time trying to determine why no debugging tool was available as an option:
Make sure you have the right device connected.
I know this sounds terribly basic, but in my case I have both SAML21 and SAML22 Xplained Pro boards, and I'd forgotten which one I had targeted for a particular project. If you have a project open that targets one, but the attached device is different, you may have this problem. The only available option becomes "Custom Programming Tool" which isn't helpful.
After connecting the correct board, I had to revisit the Tool menu and change the selected debugger/programmer to the appropriate (only) EDBG • ATML###### option.
If you're not using an Atmel Xplained board, this may not be applicable.
I spend some time about this problem as well and found out that all I had to do was go to Device and Debugging options then go to Build and select All Configurations in the configuration box then the simulator should appear under tools.
In my case it was atbackend.exe which crashed after hibernating my laptop. I had to stop Atmel studio, ensure that no AtmelStudio or atbackend processes exist in system and then start ATmel STudio again. After that Simulator appeared in Tool-Selected debugger/programmer.

WDK Driver load issue (The service cannot be started, either because it is disabled)

I have used windows 8.1 to write many drivers with no issues when loading what so ever. There seems to be some sort of issue when I try to load a new basic KMDF driver that I built in visual studio. I am able to edit source and compile new versions of driver projects built while on previous versions of windows and I assume WDK would be the true culprit here. I am able to load drivers that the original project was generated in Windows 8.1 even if I edit the source and recompile, but specifically If I try to create a new driver project through visual studio, namely the example base for Kernel Mode Driver, it fails to load with the error :
"The service cannot be started, either because it is disabled or because it has no enabled devices associated with it"
A couple points :
The driver fails to load with the same error every time, I have my own certified trusted certificate from digicert and I have tried disabling driver signature enforcement, both with the same error. So it is safe to say that certificates is not the issue.
The only main difference I can tell between the old and new WDK sources is the old version specifically has versions of windows to build from, but the new has "universal" although through settings it looks like it will just build for Windows 10.
I am not doing any stupid errors meaning, I am compiling x64, etc...
I'm starting to think that the WDK KMDF basic template may have some sort of issue with it.
I would rather not have to gut an old project (driver) to get a successful "new" driver to load.
Can you please specify is it a legacy driver or a pnp driver.
I faced a similar issue, but the mistake I was doing was compiling a pnp driver and trying to load it as a legacy driver.
To specify the difference for completion sake pnp would be a driver that comes with a AddDevice routine. Such driver are expected to have a start type as 0 and are loaded at boot time. Need to attach the driver to a specific device object in the add device routine.
The legacy drivers are one with no AddDevice routine and we call IoCreateDevice from DriverEntry itself.

"stack.cpp not found" prevents debug in VS 2013 express

I'm a rookie at C in general and VS 2013 also. I am trying to use some C code provided by a vendor in VS 2013 express. It compiles and runs without problem using the command line compiler but I would like to use the IDE.
I started a new project, C++ for console app, and I have pasted the code into the IDE and saved it as xyy.c so that it builds successfully. I thought it would be nice to have it in a GUI, so I duplicated the effort with a Win32 app project. It also builds.
The program's job is to connect to a PCI card that has Plx chip as an interface and program an FPGA. The Win32 program succeeds, even though I can't see any of the info printed by the program. The console program fails and I think it is because it fails to find the driver for the Plx chip. I thought I would get a clue by single stepping through the Win32 program to see which driver was supposed to be found.
However, after the first pass through a while loop, I get a pop up that says "Source Not Found" and "stack.cpp not found". Google wasn't any help to me.
I be grateful for any suggestions.
You might have "Enable .NET Framework source stepping" enabled (see http://msdn.microsoft.com/en-us/library/cc667410.aspx). So when you are at Stack... and trying to step into, it will actually try, but you don't have the sources for that. There is also a new experience for using the .NET framework reference source that was announced recently: http://blogs.msdn.com/b/dotnet/archive/2014/02/24/a-new-look-for-net-reference-source.aspx
I faced the same problem. I advise at the moment of receiving the information "stack.cpp not found" to look at the stack trace and check if there is something like this: "RTC".
If there is, you need to change the flag along the path (for example, set the Default or a more convenient configuration for you):
Project Properties -> C/C++ -> Code Generation -> Basic Runtime Checks
More details: https://learn.microsoft.com/en-us/cpp/build/reference/rtc-run-time-error-checks?view=msvc-160

Create Software Distribution Packages From Visual Studio

I would like to setup an automatic software distribution process, preferably from Microsoft Visual Studio, which builds my projects in all the different configurations and platforms, and packages all the created objects in a predefined folder tree structure.
The software distribution packages would be for Windows libraries and WDM driver projects written in C/C++. Each library has several different configurations (i.e. Windows 7 Release, Windows XP Release, MT/MD runtime compilation flags) for different platforms (i.e. x86 and x64). A similar thing is with the drivers. Without any automatic process to create a software distribution package, it's necessary to build all the different configurations for each platform and then copy the created objects to a predefined folder structure and then zip the created folder giving it a release name and version. This process is quite time consuming and error prone. Therefore, my goal is to automate this process using a clean a nice solution.
I've been researching about this for a few weeks already and have actually implemented a few different solutions. However non of the solutions I implemented until now is flawless whatsoever. Hence since this should be a problem that I guess many developers have already encountered, I would like to hear different opinions on what would be a nice and efficient way to do it.
Up until now I've tried the following:
A batch script and a Makefile to be used by NMAKE. This is not so good because it makes difficult to set the same build parameters that are set on the visual studio project.
Implemented a "deploy" target task (editing the .vcsproj files) which calls MSBuild of the project for each configuration/platform and copies the generated files to a distribution directory. This has the advantage that I can start the deploy activity from within visual studio but it also produces several environment variables problems, specially when building windows drivers.
Any ideas or suggested solutions will be appreciated.
Thanks in advance.
Zion
If you haven't already, add a post-build step for each lib and driver which copies the built files into your specific tree and also zips them.
If you haven't already, create one Visual Studio solution (.sln file) which builds all these projects at once.
If you haven't already, set up Build configuration using the Build | Configuration Manager dialog. Now from the IDE, you should be able to specify a specific configuration and do a Build | Rebuild Solution and make sure all the projects are successfully built.
From the command-line, you can now automate #3 by opening a Visual Studio command line prompt (which sets up the environment variables appropriately). Start devenv.exe with appropriate command-line parameters.

Windows display driver hooking, 64 bit

Once I've written a sort of a driver for Windows, which had to intercept the interaction of the native display driver with the OS. The native display driver consists of a miniport driver and a DLL loaded by win32k.sys into the session space. My goal was to meddle between the win32k.sys and that DLL. Moreover, the system might have several display drivers, I had to hook them all.
I created a standard WDM driver, which was configured to load at system boot (i.e. before win32k). During its initialization it hooked the ZwSetSystemInformation, by patching the SSDT. This function is called by the OS whenever it loads/unloads a DLL into the session space, which is exactly what I need.
When ZwSetSystemInformation is invoked with SystemLoadImage parameter - one of its parameters is the pointer to a SYSTEM_LOAD_IMAGE structure, and its ModuleBase is the module base mapping address. Then I analyze the mapped image, patch its entry point with my function, and the rest is straightforward.
Now I need to port this driver to a 64-bit Windows. Needless to say it's not a trivial task at all. So far I found the following obstacles:
All drivers must be signed
PatchGuard
SSDT is not directly exported.
If I understand correctly, PatchGuard and driver signing verification may be turned off, the driver should be installed on a dedicated machine, and we may torture it the way we want.
There're tricks to locate the SSDT as well, according to online sources.
However recently I've discovered there exists a function called PsSetLoadImageNotifyRoutine. It may simplify the task considerably, and help avoid dirty tricks.
My question are:
If I use PsSetLoadImageNotifyRoutine, will I receive notifications about DLLs loaded into the session space? The official documentation talks about "system space or user space", but does "system space" also includes the session space?
Do I need to disable the PatchGuard if I'm going to patch the mapped DLL image after it was mapped?
Are there any more potential problems I didn't think about?
Are there any other ways to achieve what I want?
Thanks in advance.
Do I need to disable the PatchGuard if I'm going to patch the mapped DLL image after it was mapped?
To load any driver on x64 it must be signed. With admin rights you can disabled PatchGuard and I personally recommend using DSEO, a GUI application made for this. Or you can bypass PatchGuard by overwriting the MBR (or BIOS), although this is typically considered a bootkit - malware.

Resources