1

現在、WinDDK 2003 で提供されている NdisProt ドライバーを実行しようとしています。ドライバーを正常にビルドしてインストールしました。

uiotestという名前のテストユーティリティが付属しています

make でユーティリティをビルドすると、正しく実行されます。

CreateFile( "\\.\\NdisProt"Visual Studio 2005 で空の win32 アプリケーション ソリューションを作成すると、 [...])`の間、ドライバーに接続できません。呼び出しは常に無効なハンドルを返します。私のプロジェクトは、make とまったく同じようにビルドされていないと思われます。make で使用する「sources」ファイルの内容は次のとおりです。

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環境からのmakeの戻り値です

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 で失敗します

4

2 に答える 2

3

それがすべての問題ではないかもしれませんが、引用されたコードから飛び出していることの 1 つは callCreateFile("\\.\\NdisProt",...)です。カーネル名前空間内のオブジェクトの正しいパス名は 2 つのバックスラッシュで始まり、C 文字列ではそれぞれを 2 つにする必要があります。過去に SO で使用されていたマークアップ言語がバックスラッシュと混同されるという問題があったため、質問を自由に編集して、提示しようとしている名前が表示されていることを確認し、それを維持するためにマークアップを修正しました。意図。

したがって、デバイス オブジェクトへのハンドルを作成するために使用される名前は次のようになります。

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

という名前のデバイス オブジェクトをアドレス指定します。

\\.\NdisProt

他に問題があるかどうか、またはそれがそのドライバーによってエクスポートされた正しい名前であるかどうかはわかりません。

通常、DDK サンプルは、MFC、ATL、WTL などに依存しないように記述されています。この結果、コードは一種の堅苦しいスタイルになりますが、DDK 自体に最初に同梱されていたツール チェーンを使用してサンプルをビルドでき、使用するツールチェーンの選択に比較的依存しないという利点があります。

ドライバーを実際にデバッグしようとする場合は、ユーザー モード コードからカーネルを介してドライバーの関連ビットへの呼び出しを追跡する必要がある場合があることに注意してください。ユーザー モード コードができるだけ単純であれば、カーネル デバッガーでこれを行うのは簡単です。これは、サンプル コードで使用されているスタイルも説明している可能性があります。

編集: Unicode と ANSI の問題が浮かんでいる場合は、幅の広い文字列を予期する API に狭い文字列が渡される場所をコードで確認し、修正する必要があります。

簡単な修正方法の 1 つは、すべての Windows API を ANSI コンパイルに切り替えることです。もちろん、現在のコード ページにない国別文字を含むファイル名には問題があります。これは、Unicode ファイル名が ANSI との間で正しく変換されることを保証する方法がないためです。

「十分」な修正の 1 つは、文字列定数をL"...". ただし、現在、コードは ANSI コンパイルに移植できないことが保証されているため、コンパイル時のアサーションを使用して定義されていることを確認しUNICODE、適切なエラー メッセージが表示されるようにしてください。

Microsoft の方針は、どちらも使用charせwchar_tず、代わりに を使用することであるようTCHARです。ヘッダー<tchar.h>は、コンパイル時にワイドまたはナロー API を選択することにより、Windows API および C ランタイム ライブラリで文字列を宣言および使用できるようにするマッピング マクロを提供します。他のプラットフォームへの移植性があまり高くないため、Windows アプリケーションでこれを行うのは間違いなく正しいことです。

ただし、TCHARs を既知の表現に変換するマクロ マジックを適切に処理するのは大変です。

どの手法を選択するかに関係なく、文字列の処理と文字表現の仮定について、慎重かつ完全なコード レビューを行う以外に方法はないと思います。

于 2009-05-08T21:55:24.597 に答える