IDebugClient8 ::OpenDumpFileWide2, méthode (dbgeng.h)
La méthode OpenDumpFileWide2 ouvre un fichier de vidage en tant que cible de débogueur.
Syntaxe
HRESULT OpenDumpFileWide2(
[in, optional] PCWSTR FileName,
[in] ULONG64 FileHandle,
[in] ULONG AlternateArch
);
Paramètres
[in, optional] FileName
Spécifie le nom du fichier de vidage à ouvrir , sauf si FileHandle n’est pas zéro, auquel cas FileName est utilisé uniquement lorsque le moteur est interrogé pour le nom du fichier de vidage. FileName doit inclure l’extension de nom de fichier. FileName peut inclure un chemin relatif ou absolu ; les chemins relatifs sont relatifs au répertoire dans lequel le débogueur a été démarré. fileName peut également être sous la forme d’une URL de fichier, en commençant par « file:// ». Si FileName spécifie un fichier d’armoire (.cab), le fichier d’armoire est recherché pour le premier fichier avec l’extension .kdmp, puis .hdmp, puis .mdmp, et enfin .dmp.
[in] FileHandle
Spécifie le handle de fichier du fichier de vidage à ouvrir. Si FileHandle est égal à zéro, nom_fichier est utilisé pour ouvrir le fichier de vidage. Sinon, si fileName n’est pas NULL, le moteur le retourne lorsqu’il est interrogé pour le nom du fichier de vidage. Si FileHandle n’est pas zéro et fileName est NULL, le moteur retourne HandleOnly pour le nom de fichier.
[in] AlternateArch
Spécifie l’argument AlternateArch qui est une constante IMAGE_FILE_MACHINE_*. Pour plus d’informations, consultez constantes de machine de fichiers image.
Ces deux constantes sont prises en charge.
IMAGE_FILE_MACHINE_AMD64 : charger comme si l’image s’exécute dans un processus x64
IMAGE_FILE_MACHINE_ARM64 : charger comme si l’image s’exécute dans un processus ARM64
Ce paramètre est pertinent uniquement si vous utilisez OpenDumpFileWide2 pour ouvrir un fichier image (et non un fichier de vidage) qui peut être mappé dans différentes architectures. Par exemple, ARM64X, où la DLL peut être chargée dans un processus x64/EC ou un processus ARM64.
Par défaut, des informations sur la DLL sont présentées à l’aide de l’architecture définie par les en-têtes d’image. Si vous appelez OpenDumpFileWide2 avec une autre architecture, les informations sont présentées à l’aide de l’architecture passée. Cela vous permet de voir les « correctifs » que le système d’exploitation aurait appliqués si la DLL a été chargée dans cette architecture de processus.
Pour plus d’informations sur ARM64X, consultez fichiers PE Arm64X.
Valeur de retour
Cette méthode peut également retourner des valeurs d’erreur. Pour plus d’informations, consultez valeurs de retour.
Remarques
Le moteur n’est pas entièrement attaché au fichier de vidage tant que la méthode WaitForEvent n’a pas été appelée. Lorsqu’un fichier de vidage est créé à partir d’un processus ou d’un noyau, des informations sur le dernier événement sont stockées dans le fichier de vidage. Une fois le fichier de vidage ouvert, la prochaine fois que l’exécution est tentée, le moteur génère cet événement pour les rappels d’événements. Seul le fichier de vidage devient disponible dans la session de débogage.
Pour plus d’informations sur les fichiers de vidage sur incident, consultez Dump-File Targets.
Exigences
| Exigence | Valeur |
|---|---|
| plateforme cible | Windows |
| d’en-tête | dbgeng.h (include Dbgeng.h) |