OSRLogoOSRLogoOSRLogo x Subscribe to The NT Insider

Everything Windows Driver Development

GoToHomePage xLoginx

    Thu, 14 Mar 2019     118020 members


  Online Dump Analyzer
OSR Dev Blog
The NT Insider
The Basics
File Systems
ListServer / Forum
  Express Links
  · The NT Insider Digital Edition - May-June 2016 Now Available!
  · Windows 8.1 Update: VS Express Now Supported
  · HCK Client install on Windows N versions
  · There's a WDFSTRING?
  · When CAN You Call WdfIoQueueP...ously

What's in a (Process) Name? Obtaining A Useful Name for the Executable Image in a Process

Over the years developers have needed or wanted to know the name of the image executing in a given process. Traditionally, this was often done using PsGetProcessImageFile Name, which returns the contents of a field in the EPROCESS structure used by the Windows OS to maintain per-process state information.

As we can see from the information in the local debugger session (See Figure 1) the process image file is little more than a field within the EPROCESS structure. Notice that the EPROCESS address is in EBP+8, making it the first - and only - parameter to this function.

Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Symbol search path is: srv*c:\symbols\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
WARNING: Local kernel debugging requires booting with /debug to work optimally.
Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: winNt, suite: Terminalserver SingleUserTS
Built by: 2600.xpsp_sp2_gdr.050301-1519
Kernel base = 0x804d7000 PsLoadedModuleList = 0x805624a0
Debug session time: Mon Aug  7 13:29:53.486 2006 (GMT-4)
System Uptime: 2 days 11:08:38.140
lkd> .reload
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols
Loading User Symbols
Loading unloaded module list
.......................*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C
lkd> u nt!PsGetProcessImageFileName
8050a14a  8bff mov edi,edi
8050a14c  55 push ebp
8050a14d  8bec mov ebp,esp
8050a14f  8b4508 mov eax,dword ptr [ebp+8]
8050a152  0574010000 add eax,174h
8050a157  5d pop ebp
8050a158  c20400 ret 4
8050a15b  8bce mov ecx,esi

Figure 1 - Local Debug Session of PsGetProcessImageFileName

Unfortunately, there are some issues with this approach:

  • Though well-known, this function is undocumented.
  • More seriously, the information contained in this field is severely limited. It contains only the first 16 (ASCII) characters of the image file name.

It is actually the second issue that often creates problems for programmers because the name of the image file means essentially nothing. For example, we've seen kernel-mode drivers in the past that validate the name of their service by checking this field. The most egregious case we've seen is when the service was called svchost.exe, which is a common name that is often spoofed.

The Proposal
We suggest a different model for acquiring this information, as shown in Figure 2.

    __in HANDLE ProcessHandle,
    __in PROCESSINFOCLASS ProcessInformationClass,
    __out_bcount(ProcessInformationLength) PVOID ProcessInformation,
    __in ULONG ProcessInformationLength,
    __out_opt PULONG ReturnLength

QUERY_INFO_PROCESS ZwQueryInformationProcess;

NTSTATUS GetProcessImageName(PUNICODE_STRING ProcessImageName)
    NTSTATUS status;
    ULONG returnedLength;
    ULONG bufferLength;
    PVOID buffer;
    PUNICODE_STRING imageName;
    PAGED_CODE(); // this eliminates the possibility of the IDLE Thread/Process

    if (NULL == ZwQueryInformationProcess) {

        UNICODE_STRING routineName;

        RtlInitUnicodeString(&routineName, L"ZwQueryInformationProcess");

        ZwQueryInformationProcess =
               (QUERY_INFO_PROCESS) MmGetSystemRoutineAddress(&routineName);

        if (NULL == ZwQueryInformationProcess) {
            DbgPrint("Cannot resolve ZwQueryInformationProcess\n");
    // Step one - get the size we need
    status = ZwQueryInformationProcess( NtCurrentProcess(),
                                        NULL, // buffer
                                        0, // buffer size

    if (STATUS_INFO_LENGTH_MISMATCH != status) {

        return status;


    // Is the passed-in buffer going to be big enough for us? 
    // This function returns a single contguous buffer model...
    bufferLength = returnedLength - sizeof(UNICODE_STRING);
    if (ProcessImageName->MaximumLength < bufferLength) {

        ProcessImageName->Length = (USHORT) bufferLength;


    // If we get here, the buffer IS going to be big enough for us, so
    // let's allocate some storage.
    buffer = ExAllocatePoolWithTag(PagedPool, returnedLength, 'ipgD');

    if (NULL == buffer) {


    // Now lets go get the data
    status = ZwQueryInformationProcess( NtCurrentProcess(),

    if (NT_SUCCESS(status)) {
        // Ah, we got what we needed
        imageName = (PUNICODE_STRING) buffer;

        RtlCopyUnicodeString(ProcessImageName, imageName);

    // free our buffer

    // And tell the caller what happened.
    return status;

Figure 2 - A New Proposal

The function itself is fairly straight-forward. It does rely on use of a single undocumented function (ZwQueryInformationProcess), but note that its counterpart (NtQueryInformationProcess) is documented. We need to use the Zw variant in order to use a kernel memory buffer.

The key element is that Windows has always stored the full path name to the executable image in order to provide this information in the auditing subsystem. This API exploits that existing stored path name.

Other Process Names
This function has been implemented to extract the process name for the current process. However, you can use one of the two methods listed below to obtain the process name for a different process:

1.  If you have a handle for the process, you can use that value instead of the NtCurrentProcess() macro. (Note that in our experience, we usually have a process object and not a process handle - the two are not interchangeable).

2.  If you have an EPROCESS address, you can use KeStackAttachProcess/KeUnstackDetachProcess to attach to the process. This technique is rather heavy-weight, so it may be a good idea to cache the information if you need to perform this operation regularly.

When using the second technique, it is important to note that the name that is returned is a cached name. This cache is not updated if the name of the original file changes after the name is first cached. In other words, if the executable image is renamed, which is typically allowed for a running executable, the name returned will be the name of the original file.

This issue is not unique. We have also observed that some file systems return the original name even after a rename (e.g., the CIFS client implementation does this on Windows XP). Thus, it may require additional processing such as through a file system filter driver to protect against similar events. For example, you may encounter a security product that relies on knowing the specific name of the image.

There are other options that a driver could also pursue such as registering for process creation/teardown events (PsSetCreateProcessNotifyRoutine) or image loading (PsSetLoadImageNotifyRoutine).

PsSetCreateProcessNotifyRoutine has limitations on the number of drivers that can register using this API. Since there is a fixed size table in the Windows OS, it is possible for this call to fail. When this occurs, a driver needs to ensure it can handle such a failure. PsSetLoadImageNotifyRoutine has the same limitation (fixed size table), but is called for all image loads, not just the original process image. Therefore, it includes drivers, DLLs, executables, etc.

The bottom line is that all of these approaches provide a useful name because they include the full path name. This is vastly superior to using the short ASCII eye-catching name that is stored in the EPROCESS structure. A word of caution - if you decide to use the debug level name, use it for nothing more than debugging  since it is not reliable and cannot be relied on for any sort of security check.

We chose to use the proposed technique because it works in all circumstances and does not rely upon a registration that might potentially fail. In your own driver you might implement both this mechanism and a cache-based mechanism tied to the process creation logic.

User Comments
Rate this article and give us feedback. Do you find anything missing? Share your opinion with the community!
Post Your Comment

"It still has issues"
This method fails in this scenario:

1) Run process C:\aaaa\test.exe 2) After process ends, rename C:\aaaa to C:\bbbb 3) Run process C:\bbbb\test.exe

After that, ZwQueryInformationProcess still returns C:\aaaa\test.exe

07-Sep-09, Ladislav Zezula

"check filemon code"
check filemon code ..it works on win2000 also...

13-Jun-09, harish bisht

"Calling MmGetSystemRoutineAddress while in IRQL APC_LEVEL"
I have tried to call GetProcessImageName while the IRQL is APC_LEVEL and nothing happened , GetProcessImageName return the image name with its full path , but according the msdn MmGetSystemRoutineAddress must be called under PASSIVE_LEVEL only. any idea ?

11-May-08, tzachi or

"Windows 2000 Support"
Unfortunately, this technique works only for XP and more recent. Windows 2000 doesn't maintain this information and there's no simple way to duplicate this (basically, you have to watch with a file system filter driver for when a file object is created with EXECUTE access and the name used at that point.)

18-Sep-07, Tony Mason

"process image name"
I cannot use the parameter 'ProcessImageFileName' in win2k, the symbol is unresolved... Is there an equivalent method in Win2k to get a process image' full path?

04-Jan-07, matteo formica

According to http://www.codeproject.com/system/InterceptWinAPICalls.asp,

the event set by PsSetCreateProcessNotifyRoutine is often fired when the process has already been started. This is problematic when I need to use the process full image name before the event gets fired somehow. For example, I might intercept NtCreateThread and wants to use the process name inside the NewNtCreateThread routine. In this case, I wouldn't get the process name because the event has not been fired yet.


03-Jan-07, HaeRim Lee

This new proposal uses ProcessImageFileName which is not supported on Win2K as far as I know.

Please make this good proposal work on Win2K too.

There are people still liviing in the world of Win2K.

We can't dump them unfortunately.

Best Regards.


03-Jan-07, HaeRim Lee

"Does this new proposal work on all windows platforms win2k and later?"
I want it to work on all platforms for Win2k and later.


03-Jan-07, HaeRim Lee

"It is good but ..."
How to get the process fullpath name int this way? c:\...\www.exe ?

11-Dec-06, talker rhq

if (NULL == ZwQueryInformationProcess) { DbgPrint("Cannot resolve ZwQueryInformationProcess\n"); } I would think that you would want to return after confirming that the pointer is null rather than actually making the call.

Also what is the value for ProcessImageFileName ?

27-Sep-06, James Donelson

Post Your Comments.
Print this article.
Email this article.
bottom nav links