Использование утилит для тестирования WinDDK с Visual Studio 2005

Question

В настоящее время я пытаюсь запустить драйвер NdisProt, указанный WinDDK 2003. Я успешно создал и установил драйвер.

Он поставляется с тестовой утилиты под названием uiotest

Когда я строю утилиту с указанием марки он работает правильно.

Когда я создаю пустое прикладное решение win32 с Visual Studio 2005, он не может подключиться к драйверу во время CreateFile("\\.\\NdisProt" [...]) `. Вызов всегда возвращает недопустимый дескриптор. Я подозреваю, что мой проект не построен точно так же, как и с make. Вот содержимое файла «источники», используемый сделать

TARGETNAME=uiotest 
TARGETPATH=obj 
TARGETTYPE=PROGRAM 

C_DEFINES=$(C_DEFINES) -D_WIN32WIN_ 

# MSC_WARNING_LEVEL=/W4 

UMTYPE=console 
USE_MSVCRT=1 

TARGETLIBS=\ 
    $(SDK_LIB_PATH)\user32.lib 

INCLUDES=..\sys 

SOURCES=\ 
    uiotest.c 

Я добавил Lib путь и включают в себя путь к моему проекту

вот что делает отдачу от DDK environement

cl -nologo -Ii386\ -I. -ID:\WINDDK\3790~1.183\inc\mfc42 -I..\sys -Iobjfre_wxp_x8 
6\i386 -ID:\WINDDK\3790~1.183\inc\wxp -ID:\WINDDK\3790~1.183\inc\wxp -ID:\WINDDK 
\3790~1.183\inc\crt -D_X86_=1 -Di386=1 -DSTD_CALL -DCONDITION_HANDLING=1 -DNT 
_INST=0 -DWIN32=100 -D_NT1X_=100 -DWINNT=1 -D_WIN32_WINNT=0x0501 /DWINVER=0x0501 
-D_WIN32_IE=0x0603 -DWIN32_LEAN_AND_MEAN=1 -DDEVL=1 -D__BUILDMACHINE__=WinDD 
K -DFPO=0 -DNDEBUG -D_DLL=1 -D_MT=1 -D_WIN32WIN_  /c /Zl /Zp8 /Gy /Gm- /W3 
/WX /Gz /GX- /GR- /GF /GS /G6 /Ze /Gi- /QIfdiv- /hotpatch -Z7 /Oxs /Oy- -F 
ID:\WINDDK\3790~1.183\inc\wxp\warning.h .\uiotest.c 
uiotest.c 
     link -out:objfre_wxp_x86\i386\uiotest.exe -machine:ix86 @C:\Temp\nm88BE. 
tmp 
Microsoft (R) Incremental Linker Version 7.10.4035 
Copyright (C) Microsoft Corporation. All rights reserved. 

-MERGE:_PAGE=PAGE 
-MERGE:_TEXT=.text 
-SECTION:INIT,d 
-OPT:REF 
-OPT:ICF 
-IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221 
-INCREMENTAL:NO 
-FULLBUILD 
/release 
-NODEFAULTLIB 
/WX 
-debug 
-debugtype:cv 
-version:5.1 
-osversion:5.1 
/functionpadmin:5 
/safeseh 
/opt:nowin98 
-merge:.rdata=.text 
/pdbcompress 
-STACK:0x40000,0x2000 
/tsaware 
-subsystem:console,4.00 
-base:@D:\WINDDK\3790~1.183\bin\coffbase.txt,usermode 
-entry:mainCRTStartup 
objfre_wxp_x86\i386\uiotest.obj 
D:\WINDDK\3790~1.183\lib\wxp\i386\BufferOverflowU.lib 
D:\WINDDK\3790~1.183\lib\crt\i386\msvcrt.lib 
D:\WINDDK\3790~1.183\lib\wxp\i386\advapi32.lib 
D:\WINDDK\3790~1.183\lib\wxp\i386\kernel32.lib 
D:\WINDDK\3790~1.183\lib\wxp\i386\user32.lib 
D:\WINDDK\3790~1.183\lib\wxp\i386\sehupd.lib 

Я не слишком уверен, что проверить, что происходит, поэтому любая помощь будет заметна. Новый проект компилируется и запускается, но CreateFile() не работает с INVALID_HANDLE_VALUE

Answer 1

Это может быть не вся проблема, но одна вещь, которая выскочит из котируемого кода, - это вызов CreateFile("\\.\\NdisProt",...). Правильное имя пути объекта в пространстве имен ядра начинается с двух обратных косых черт, каждый из которых должен быть удвоен в строке C. У меня были проблемы с языком разметки, используемым в SO, смущенным обратными косыми чертами в прошлом, поэтому я позволил вам отредактировать ваш вопрос, чтобы убедиться, что я видел имя, которое вы намеревались представить, и исправить разметку, чтобы сохранить это намерение.

Таким образом, имя, используемое для создания дескриптора объекта устройства должно выглядеть

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

обратиться объект устройства с именем

\\.\NdisProt 

Я понятия не имею, если есть какие-либо другие вопросы , или даже если это правильное имя, экспортированное этим драйвером.

Образцы DDK обычно записываются без зависимостей от таких вещей, как MFC, ATL, WTL и т. П. Это приводит к некоторому стилизованному стилю в коде, но имеет преимущество, что образцы могут быть построены с помощью цепочки инструментов, первоначально поставляемой с самим DDK, и относительно независимы от выбора используемой инструментальной цепочки.

Обратите внимание, что если вы в конечном итоге попытаетесь отладить драйвер, вам может потребоваться отследить вызов из кода режима пользователя через ядро ​​и в соответствующие биты драйвера. Выполнение этого с помощью отладчика ядра проще, если код режима пользователя максимально прост. Это также может объяснить стиль, используемый в примере кода.

Редактировать: Если есть проблема с Unicode vs. ANSI, то вы должны просмотреть свой код для мест, где узкие строки передаются API, которые ожидают широких строк и исправляют их.

Одним из простых исправлений является переход на компиляцию ANSI для всех API Windows. Конечно, теперь у вас есть проблемы с именами файлов, которые включают национальные символы, не входящие в вашу текущую кодовую страницу, поскольку невозможно гарантировать, что имя файла Unicode может быть правильно переведено и из ANSI.

Одно исправление, которое может быть «достаточно хорошим», состоит в том, чтобы сделать строковые константы широкими, записав их L"...". Однако теперь ваш код гарантированно не переносится обратно на компиляцию ANSI, поэтому обязательно используйте утверждение времени компиляции, чтобы убедиться, что UNICODE определен так, чтобы вы получили сообщение об ошибке.

Линия партии в Microsoft, похоже, никогда не использует ни char, либо wchar_t, а вместо этого использовать TCHAR. Заголовок <tchar.h> поставляет макросы сопоставления, которые позволяют объявлять и использовать строки в API Windows и в библиотеках времени выполнения C, выбирая широкий или узкий API во время компиляции. Возможно, это правильная вещь в приложении Windows, поскольку она уже не очень переносима на другие платформы.

Однако, получение макроса магии право иметь дело с переводом TCHAR s к известному представлению - это боль.

Независимо от того, какой метод вы выберете, я не вижу выхода из тщательного и полного обзора кода для обработки строк и предположений о представлении символов.

Answer 2

Половина soved:

CreateFile ссылается CreateFileW, который ожидает строки Юникода. Когда я нажимаю CreateFileA, он работает.