How to Remove Hex Digits Prepended to a Windows Process Name

Question

I have created a 64-bit executable using Visual Studio 2015, intended to be run on Windows 7. The executable is a C++ wrapper that calls the main method in a Java application via JNI. The application runs as expected, but in Windows Task Manager, on the "Process" tab, my application name has been prepended with 16 hex digits. So even though my application compiles to "someapp.exe", it is listed as "80005b29594d4a91someapp.exe" in the process list when I run it. Does anyone know why this is happening, and how to make it show up as just "someapp.exe" in the Task Manager?

EDIT 1:

I should note that the hex string is always the same when it appears in the name. However, there is a small percentage of the time I run my application when it actually has the expected name of "someapp.exe". I have not been able to figure out the pattern of when the hex string is prepended and when it is not, but I estimate the hex string appears 98% of the time it is executed.

EDIT 2:

This appears to be related somehow to the use of JNI. When I remove the JNI calls, this stops occuring altogether. The following represents the entirety of the C++ code making up the "someapp" application:

#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;
}

I have tried to remove the arguments passed to the Java main method, but that had no affect on the outcome.

EDIT 3:

Thanks to the suggestion from 1201ProgramAlarm, I realized that this was actually related to running from a dynamic ClearCase view. The "Image Path Name" column in the Task Manager was one of the following values, which directly correlates with the incorrect "Image Name" symptom that I was observing:

\view\view-name\someapp-path\someapp.exe
\view-server\views\domain\username\view-name.vws.s\00035\8‌​0005b29594d4a91somea‌​pp.exe

I would still like to know why this is happening, but since this only affects our development environment, fixing it has become low priority. For anyone else experiencing this problem, the following represents the relevant software installed in my environment:

• Windows 7 Enterprise x64 SP1
• Rational ClearCase Explorer 7.1.2.8
• Visual Studio 2015 Update 3
• Java x64 JDK 8u112

Answer 1

Run your application from a drive that isn't a ClearCase dynamic view.

The Image Name of the running process reference a file in a ClearCase view Storage (\\view\view-name\someapp-path\someapp.exe => \\view-server\views\domain\username\view-name.vws\.s\00035\8‌​0005b29594d4a91somea‌​pp.exe), the .vws meaning view storage.

See "About dynamic view storage directories":

Every view has a view storage directory. For dynamic views, this directory is used to keep track of which versions are checked out to your view and to store view-private objects

So a view storage exists both for snapshot and dynamic view.
But for dynamic view, that storage is also used to keep a local copy of the file you want to read/execute (all the other visible files are accessed through the network with MVFS: MultiVersion File System)

That is why you see \\view-server\views\domain\username\view-name.vws\.s\00035\8‌​0005b29594d4a91somea‌​pp.exe when you execute that file: you see the local copy done through MVFS by ClearCase.

Would you have used a snapshot view, you would not have seen such a complex path, since a snapshot view by its very nature does copy all files locally.

It appears as though the path is "correct" when I have not accessed the MVFS mount recently using Windows Explorer

That means the executable executed by Windows is still the correct one, while MVFS will be busy downloading that same executable from the Vob onto the inner folder of the view storage.
But once you re-execute it, that executable is already there (in the view storage), so MVFS will communicate its full path (again, in the view storage) to Windows (as seen in the Process Explorer)