Comment faire pour supprimer les chiffres hexadécimaux ajoutés à un nom de processus Windows

Question

J'ai créé un exécutable 64 bits à l'aide de Visual Studio 2015, destiné à être exécuté sur Windows 7. L'exécutable est un wrapper C++ qui appelle la méthode principale dans une application Java via JNI. L'application s'exécute comme prévu, mais dans le Gestionnaire des tâches de Windows, dans l'onglet "Process", mon nom d'application a été ajouté au préalable avec 16 chiffres hexadécimaux. Donc, même si mon application compile à "someapp.exe", il est répertorié comme "80005b29594d4a91someapp.exe" dans la liste des processus lorsque je l'exécute. Est-ce que quelqu'un sait pourquoi cela se produit, et comment le faire apparaître comme "someapp.exe" dans le Gestionnaire des tâches?

EDIT 1:

Je dois noter que la chaîne hexagonale est toujours le même quand il apparaît dans le nom. Cependant, il y a un petit pourcentage du temps que je cours mon application quand elle a réellement le nom attendu de "someapp.exe". Je n'ai pas été capable de comprendre le modèle de quand la chaîne hexadécimale est préfixée et quand elle ne l'est pas, mais j'estime que la chaîne hexadécimale apparaît 98% du temps où elle est exécutée.

EDIT 2:

Cela semble être lié en quelque sorte à l'utilisation de JNI. Lorsque je supprime les appels JNI, cela s'arrête complètement. Ce qui suit représente la totalité du code C++ constituant l'application « someapp »:

#include <jni.h> 
#include <Windows.h> 

#define STRING_CLASS "java/lang/String" 

int main(size_t const argc, char const *const argv[]) { 
    // Modify the DLL search path 
    SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32 | 
     LOAD_LIBRARY_SEARCH_DEFAULT_DIRS | LOAD_LIBRARY_SEARCH_USER_DIRS); 
    SetDllDirectoryA(R"(C:\Program Files\Java\jdk1.8.0_112\jre\bin\server)"); 

    // Create and populate the JVM input arguments 
    JavaVMInitArgs vm_args; 
    vm_args.version   = JNI_VERSION_1_8; 
    vm_args.ignoreUnrecognized = JNI_FALSE; 
    vm_args.nOptions   = 2; 
    vm_args.options   = new JavaVMOption[vm_args.nOptions]; 

    // Set command-line options 
    vm_args.options[0].optionString = "-Dfile.encoding=UTF-8"; 
    vm_args.options[1].optionString = "-Djava.class.path=someapp.jar"; 

    // Create the JVM instance 
    JavaVM *jvm; 
    JNIEnv *env; 
    JNI_CreateJavaVM(&jvm, reinterpret_cast<void**>(&env), &vm_args); 

    // Get the main entry point of the Java application 
    jclass mainClass = env->FindClass("myNamespace/MainClass"); 
    jmethodID mainMethod = env->GetStaticMethodID(
     mainClass, "main", "([L" STRING_CLASS ";)V"); 

    // Create the arguments passed to the JVM 
    jclass stringClass = env->FindClass(STRING_CLASS); 
    jobjectArray mainArgs = env->NewObjectArray(
     static_cast<jsize>(argc - 1), stringClass, NULL); 
    for (size_t i(1); i < argc; ++i) { 
     env->SetObjectArrayElement(mainArgs, 
      static_cast<jsize>(i - 1), env->NewStringUTF(argv[i])); 
    } 
    env->CallStaticVoidMethod(mainClass, mainMethod, mainArgs); 

    // Free the JVM, and return 
    jvm->DestroyJavaVM(); 
    delete[] vm_args.options; 
    return 0; 
} 

J'ai essayé de supprimer les arguments passés à la méthode Java principale, mais n'avait une incidence sur les résultats.

EDIT 3:

Merci à la suggestion de 1201ProgramAlarm, j'ai réalisé que cela était en fait lié à l'exécution d'une vue ClearCase dynamique. La colonne "Image Path Name" dans le Gestionnaire des tâches était l'une des valeurs suivantes, qui est directement corrélée avec le symptôme "Image Name" incorrect que j'observais:

\ view \ view-name \ someapp-path \ someapp.exe
\ view-server \ vues \ domaine \ nom d'utilisateur \ view-name.vws.s \ 00035 \ 8 0005b29594d4a91somea pp.exe

J'aime toujours savoir pourquoi ce qui se passe , mais puisque cela n'affecte que notre environnement de développement, le fixer est devenu une priorité basse. Pour tous ceux qui connaissent bien ce problème, ce qui suit représente le logiciel correspondant installé dans mon environnement:

• Windows 7 Enterprise x64 SP1
• Rational ClearCase Explorateur 7.1.2.8
• Visual Studio 2015 Mise à jour 3
• Java x64 JDK 8u112

Answer 1

Exécutez votre application à partir d'un lecteur qui n'est pas une vue dynamique ClearCase.

Le nom de l'image du processus en cours d'exécution référence à un fichier dans une vue ClearCase stockage (\\view\view-name\someapp-path\someapp.exe => \\view-server\views\domain\username\view-name.vws\.s\00035\8‌​0005b29594d4a91somea‌​pp.exe), le stockage .vws vue sens.

Voir "About dynamic view storage directories":

Chaque vue a un répertoire de stockage de vue. Pour les vues dynamiques, ce répertoire est utilisé pour garder une trace des versions extraites de votre vue et pour stocker les objets view-private

Un stockage de vue existe donc à la fois pour l'instantané et la vue dynamique.
Mais pour une vue dynamique, que le stockage est également utilisé pour conserver une copie locale du fichier que vous voulez lire/exécuter (tous les autres fichiers visibles sont accessibles via le réseau avec MVFS: MultiVersion File System)

C'est pourquoi vous voyez \\view-server\views\domain\username\view-name.vws\.s\00035\8‌​0005b29594d4a91somea‌​pp.exe lorsque vous exécutez ce fichier: vous voyez la copie locale effectuée via MVFS par ClearCase.

Si vous aviez utilisé une vue d'instantané, vous n'auriez pas vu un chemin aussi complexe, puisqu'une vue d'instantané par sa nature copie les fichiers tous les fichiers localement.

Il semble que le chemin est « correct » quand je ne l'ai pas accédé aux MVFS mount récemment avec Windows Explorer

Cela signifie que l'exécutable exécuté par Windows est toujours le bon, alors que MVFS sera être occupé à télécharger ce même exécutable à partir du Vob sur le dossier interne de la vue de stockage.
Mais une fois que vous l'aurez réexécuté, cet exécutable est déjà là (dans le stockage de vue), ainsi MVFS communiquera son chemin complet (encore, dans le stockage de vue) à Windows (comme vu dans l'Explorateur de processus)