Méthode IDebugClient8 ::OpenDumpFileWide2 (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 égal à 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 d’accès 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, 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, FileName est utilisé pour ouvrir le fichier de vidage. Sinon, si FileName n’a pas la valeur NULL, le moteur le retourne lorsqu’il est interrogé pour le nom du fichier de vidage. Si FileHandle n’est pas égal à zéro et FileName a la valeur 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écutait dans un processus x64

• IMAGE_FILE_MACHINE_ARM64 : charger comme si l’image s’exécutait dans un processus ARM64

Ce paramètre n’est pertinent que si vous utilisez OpenDumpFileWide2 pour ouvrir un fichier image (et non un fichier de vidage) qui peut être mappé à 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, les 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 architecture différente, les informations sont présentées à l’aide de l’architecture qui a été passée. Cela vous permet de voir les « correctifs » que le système d’exploitation aurait appliqués si la DLL avait été chargée dans cette architecture de processus.

Pour plus d’informations sur ARM64X, consultez Fichiers PE Arm64X.

Valeur retournée

Cette méthode peut également retourner des valeurs d’erreur. Pour plus d’informations, consultez Valeurs de retour.

Remarques

Le moteur ne s’attache pas complètement 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 tentative d’exécution, le moteur génère cet événement pour les rappels d’événements. Ce n’est qu’alors que 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.

Configuration requise

Voir aussi

DEBUG_CLIENT_CONTEXT

IDebugClient8