Balder is able to provide a valuable set a services to third party vendors working on Windows kernel mode development projects.
Please consider the descriptions below and go to the "Contact Us" tab for information on requesting services. The types of services listed below are ordered in approximate terms of cost.
If you are mostly making progress but are running into a problem where you need an aspect of system operation explained in more detail or more specifically to your situation, then Balder can provide you the technically correct and complete answers. This would be for the experienced developer that just runs into a few problems every now and again.
With David's experience from five years of designing Windows NT file systems, Balder can help you understand the complexities specific to your situation, especially the folklore steeped areas of synchronization, cache coherency, and general kernel mode component interactions. The result will be completely avoiding subtle traps that in some cases took years to resolve and make your product a good citizen file system or filter driver that lives up the quality of every other kernel component in Windows.
Balder can perform kernel debugging of driver crashes, even via a modem connected to the serial port of your crashed machine, or alternatively by FTP'ing the memory.dmp file to Balder's site. After 5 years and analyzing literally thousands of crashes, David is very proficient.
Problem with a deadlock in Windows when running your driver? Tracking these down was one of David's specialties while at Microsoft. Again Balder can debug over a modem and find your problem.
What has been successful with some current clients is listening to the kind of problems they are having getting their products to work on NT, such as driver porting issues or nuances of the file I/O APIs semantics. Balder can then explain to them techniques that will accomplish their task and write sample code that in a simple but comprehensive way demonstrates the techniques. Note that Balder's policy is to only demonstrate behavior that is documented in the Win32 SDK, i.e. no undocumented side effects or APIs will be explained in any way -- don't ask. Usually however, there are documented, if obscure, ways to accomplish your task. Clients are free to cut and paste the sample code and both Balder and the client have perpetual, non-exclusive, worldwide rights to do whatever they want with the sample code.
The sample code is usually just a console character mode APPs and/or a modified DDK driver sample that demonstrates the required functionality. Balder focuses entirely on the Windows issues involved -- no pretty GUI. Sometimes as the implementation evolves, issues will come up that hadn't been considered (NT is an extremely complex system), and those are solved as well in the sample code. Such blocking issues can be very frustrating for someone without the necessary experience/tools when only a theoretical solution is provided. The net result is that you get a complete, almost turnkey, solution sooner.