ansaurus

Question

Using WinDDK test utilities with Visual Studio 2005

Answer 1

+3 A:

It may not be the whole problem, but one thing that leaps out from the code quoted is the call CreateFile("\\.\\NdisProt",...). The correct path name of an object in the kernel name space begins with two backslashes, each of which needs to be doubled in a C string. I've had problems with the markup language used at SO being confused by backslashes in the past, so I took the liberty of editing your question to make sure I was seeing the name you intended to present, and to fix the markup to preserve that intent.

So, the name used to create a handle to the device object should look like

CreateFile("\\\\.\\NdisProt",...)

to address the device object named

\\.\NdisProt

I have no idea if there are any other issues, or even if that is the correct name exported by that driver.

The DDK samples are generally written to be free of dependencies on things like MFC, ATL, WTL, and the like. This results in a kind of stilted style in the code, but it has the benefit that the samples can be built with the tool chain that originally shipped with the DDK itself and are relatively independent of the choice of toolchain used.

Note that if you end up trying to really debug a driver, you might need to track a call from the user mode code through the kernel and into the relevant bits of the driver. Doing that with the kernel debugger is easier if the user mode code is as simple as possible. This might also explain the style used in the sample code.

Edit: If there is also a Unicode vs. ANSI issue floating, then you should review your code for places where narrow strings are passed to APIs that expect wide strings and fix them.

One fix that is easy would be to switch to an ANSI compile for all Windows APIs. Of course, now you have problems with file names that include national characters not in your current code page since there is no way to guarantee that the Unicode file name can be correctly translated to and from ANSI.

One fix that might be "good enough" is to make string constants wide by writing them L"...". However, now your code is guaranteed not to be portable back to an ANSI compile, so be sure to use a compile-time assertion to verify that UNICODE is defined so that you get a good error message then.

The party line at Microsoft seems to be to never use either char or wchar_t but to instead use TCHAR. The header <tchar.h> supplies mapping macros that allow strings to be declared and used in the Windows API and in the C runtime libraries by choosing the wide or narrow API at compile time. Arguably, this is the correct thing to do in a Windows application since it is already not very portable to other platforms.

However, getting the macro magic right to deal with translating TCHARs to a known representation is a pain.

Regardless of which technique you choose, I don't see any way out of doing a careful and complete code review for string handling and character representation assumptions.

RBerteig 2009-05-08 21:55:24

Answer 2

A:

Half soved :

CreateFile is referencing CreateFileW which waits for a unicode string. When I force CreateFileA it works.

Eric 2009-05-11 14:03:10

Passing a narrow string to CreateFileW would probably generate a compiler warning when you compile the program. What other compiler warnings are you not telling us about?

bk1e 2009-05-11 15:51:31

ansaurus

tags:

views:

answers:

Using WinDDK test utilities with Visual Studio 2005

related questions