Utilisation des utilitaires de test WinDDK avec Visual Studio 2005

Question

J'essaie actuellement d'exécuter le pilote NdisProt fourni par WinDDK 2003. J'ai compilé et installé le pilote avec succès.

Il est livré avec un utilitaire de test nommé uiotest

Lorsque je construis l'utilitaire avec make il fonctionne correctement. Lorsque je crée une solution d'application win32 vide avec Visual Studio 2005, il ne peut pas se connecter au pilote pendant CreateFile("\\.\\NdisProt" [...]) `. L'appel renvoie toujours un handle non valide. Je soupçonne que mon projet n'est pas construit exactement comme avec make. Voici le contenu de la « sources » fichier utilisé par faire

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 

J'ai ajouté le chemin lib et chemin d'inclusion à mon projet

ici est ce qui rend le rendement de l'environement DDK

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 

Je ne sais pas trop quoi vérifier pour savoir ce qui se passe, donc toute aide serait appréciable. Le nouveau projet compile et exécute, mais le CreateFile() échoue avec INVALID_HANDLE_VALUE

Answer 1

Il peut ne pas être le problème entier, mais une chose qui saute du code cité est l'appel CreateFile("\\.\\NdisProt",...). Le chemin d'accès correct d'un objet dans l'espace de nom du noyau commence par deux barres obliques inverses, chacune devant être doublée dans une chaîne C. J'ai eu des problèmes avec le langage de balisage utilisé à SO étant confondu par les antislash dans le passé, donc je me suis permis de modifier votre question pour m'assurer que je voyais le nom que vous vouliez présenter, et de corriger le balisage pour le conserver intention.

Ainsi, le nom utilisé pour créer une poignée à l'objet de l'appareil devrait ressembler à

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

pour traiter l'objet périphérique nommé

\\.\NdisProt 

Je ne sais pas s'il y a d'autres questions , ou même si c'est le bon nom exporté par ce pilote.

Les exemples DDK sont généralement écrits pour être dépourvus de dépendances sur des choses telles que MFC, ATL, WTL et similaires. Il en résulte une sorte de style guindé dans le code, mais il a l'avantage que les échantillons peuvent être construits avec la chaîne d'outils qui était initialement fournie avec le DDK lui-même et sont relativement indépendants du choix de la chaîne d'outils utilisée. Notez que si vous essayez de vraiment déboguer un pilote, vous devrez peut-être suivre un appel du code du mode utilisateur à travers le noyau et dans les bits pertinents du pilote. Faire cela avec le débogueur du noyau est plus facile si le code du mode utilisateur est aussi simple que possible. Cela peut également expliquer le style utilisé dans l'exemple de code. Si un problème lié à Unicode ou ANSI est également présent, vérifiez votre code pour les endroits où des chaînes étroites sont transmises aux API qui attendent des chaînes étendues et les corrigent. Un correctif simple serait de passer à une compilation ANSI pour toutes les API Windows. Bien sûr, vous avez maintenant des problèmes avec les noms de fichiers qui incluent des caractères nationaux qui ne figurent pas dans votre page de codes actuelle, car il n'y a aucun moyen de garantir que le nom de fichier Unicode puisse être correctement traduit vers et depuis ANSI.Un correctif qui peut être "assez bon" est de faire des chaînes de caractères de large en les écrivant L"...". Cependant, maintenant votre code est garanti ne pas être portable vers une compilation ANSI, alors assurez-vous d'utiliser une assertion à la compilation pour vérifier que UNICODE est défini pour que vous obteniez un bon message d'erreur.

La ligne de parti chez Microsoft semble être de ne jamais utiliser char ou wchar_t mais d'utiliser à la place TCHAR. L'en-tête <tchar.h> fournit des macros de mappage qui permettent aux chaînes d'être déclarées et utilisées dans l'API Windows et dans les bibliothèques d'exécution C en choisissant l'API large ou étroite au moment de la compilation. On peut dire que c'est la bonne chose à faire dans une application Windows puisqu'elle n'est déjà pas très portable sur d'autres plateformes. Cependant, obtenir la magie de la macro pour traiter la traduction de TCHAR en une représentation connue est pénible. Quelle que soit la technique que vous choisissez, je ne vois pas d'autre moyen de procéder à une révision de code minutieuse et complète pour la gestion des chaînes et les hypothèses de représentation des caractères.

Answer 2

Demi soved:

CreateFile fait référence CreateFileW qui attend une chaîne de caractères Unicode. Quand je force CreateFileA cela fonctionne.