Как удалить шестнадцатеричные цифры, добавленные к имени процесса Windows

Я создал 64-разрядный исполняемый файл с использованием Visual Studio 2015, предназначенный для запуска в Windows 7. Этот исполняемый файл представляет собой оболочку C ++, которая вызывает основной метод в приложении Java через JNI. Приложение работает должным образом, но в диспетчере задач Windows на вкладке «Процесс» в имени моего приложения добавлено 16 шестнадцатеричных цифр. Поэтому, хотя мое приложение компилируется в «someapp.exe», оно отображается в списке процессов как «80005b29594d4a91someapp.exe», когда я его запускаю. Кто-нибудь знает, почему это происходит, и как сделать так, чтобы он отображался как «someapp.exe» в диспетчере задач?

РЕДАКТИРОВАТЬ 1:

Я должен отметить, что шестнадцатеричная строка всегда одинакова, когда она появляется в имени. Тем не менее, есть небольшой процент времени, когда я запускаю свое приложение, когда оно на самом деле имеет ожидаемое имя «someapp.exe». Я не смог выяснить, когда начинается шестнадцатеричная строка, а когда нет, но я считаю, что шестнадцатеричная строка появляется в 98% случаев, когда она выполняется.

РЕДАКТИРОВАТЬ 2:

Похоже, это как-то связано с использованием JNI. Когда я удаляю вызовы JNI, это вообще прекращается. Ниже представлен полный код C ++, составляющий приложение 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;
}

Я попытался удалить аргументы, передаваемые основному методу Java, но это никак не повлияло на результат.

РЕДАКТИРОВАТЬ 3:

Благодаря предложению 1201ProgramAlarm я понял, что это на самом деле связано с запуском из динамического представления ClearCase. Столбец «Имя пути к изображению» в диспетчере задач представлял собой одно из следующих значений, которое напрямую коррелирует с неправильным симптомом «Имя изображения», который я наблюдал:

\ Вид \ вид имя \ someapp-путь \ someapp.exe
\ Вид-сервер \ Views \ домен \ имя пользователя \ показам name.vws.s \ 00035 \ 8 0005b29594d4a91somea pp.exe

Я все еще хотел бы знать, почему это происходит, но, поскольку это влияет только на нашу среду разработки, исправление этого стало низким приоритетом. Для тех, кто сталкивается с этой проблемой, следующее представляет соответствующее программное обеспечение, установленное в моей среде:

  • Windows 7 Корпоративная x64 SP1
  • Rational ClearCase Explorer 7.1.2.8
  • Visual Studio 2015, обновление 3
  • Java x64 JDK 8u112

2

Решение

Запустите приложение с диска, который не является динамическим представлением ClearCase.

Имя изображения запущенного процесса ссылается на файл в представлении ClearCase Storage (\\view\view-name\someapp-path\someapp.exe =>
\\view-server\views\domain\username\view-name.vws\.s\00035\8‌​0005b29594d4a91somea‌​pp.exe), .vws смысл просмотра хранилища.

Увидеть «О каталогах хранилищ с динамическим представлением«:

Каждое представление имеет каталог хранилища представлений. Для динамических представлений этот каталог используется для отслеживания того, какие версии извлечены для вашего представления, и для хранения закрытых для просмотра объектов.

Таким образом, хранилище представлений существует как для снимка, так и для динамического представления.
Но для динамического просмотра это хранилище также используется для хранения локальной копии файла, который вы хотите прочитать / выполнить (все остальные видимые файлы доступны через сеть с MVFS: файловая система MultiVersion)

Вот почему вы видите \\view-server\views\domain\username\view-name.vws\.s\00035\8‌​0005b29594d4a91somea‌​pp.exe когда вы выполняете этот файл: вы видите локальную копию, выполненную через MVFS с помощью ClearCase.

Если бы вы использовали представление снимка, вы бы не увидели такой сложный путь, поскольку представление снимка по самой своей природе копирует все файлы локально.

Кажется, что путь «правильный», если я недавно не обращался к монтированию MVFS с помощью проводника Windows

Это означает, что исполняемый Windows исполняемый файл по-прежнему правильный, а MVFS будет загружать этот же исполняемый файл из Vob во внутреннюю папку хранилища представлений.
Но после повторного выполнения этот исполняемый файл уже существует (в хранилище представлений), поэтому MVFS сообщит свой полный путь (опять же, в хранилище представлений) Windows (как видно в Process Explorer)

2

Другие решения

Других решений пока нет …