Hi All,
Consider this situation…
I had run a exe, then I moved it to other place.
Now, this file can not be deleated as the process is running that means OS knows this executable is running in memory, but if I enumarate loaded modules using PSAPI or toolhelp APIs then they return old path where file is not present. My requirement is that I want to get the current path of executable running in memory even if it is moved to other place. Can it be done in usermode? How?
Thanks & Regards,
Amit.
You answered your own question : “this file can not be deleated as the
process is running”. Win32 executables are memory mapped into a process’
address space. Even if you can get the file system to delete the
executable, it is still there when viewed from that process. Other
processes may or may not be able to see that executable, but usually Windows
protects currently running executables as the code is paged in as needed.
If memory pressure is sufficient, when a page of code is not being used it
will be removed from physical memory until needed. Just because you ‘moved’
a file, does not mean a currently running process will ‘switch’ to the new
copy. It will continue to use the file it began from.
wrote in message news:xxxxx@ntdev…
> Hi All,
>
> Consider this situation…
>
> I had run a exe, then I moved it to other place.
> Now, this file can not be deleated as the process is running that means OS
> knows this executable is running in memory, but if I enumarate loaded
> modules using PSAPI or toolhelp APIs then they return old path where file
> is not present. My requirement is that I want to get the current path of
> executable running in memory even if it is moved to other place. Can it be
> done in usermode? How?
>
> Thanks & Regards,
> Amit.
>
I am going to give you a bit more detailed explanation to the concepts behind David’s post…
When you create a process, first of all, you open executable file, then create an executable section that is backed up by the file, and then call ZwCreateProcess() ( or ZwCreateProcessEx()) that, among other things, loads executable image into RAM. If memory pages of the target process don’t get accessed for a while or if the system is low on memory, they get swapped to the disk and are brought back to RAM when they get accessed.
I hope by now you already see the potential problem here - if these pages are written to the original file (i.e. everything works the way it does with memory-mapped files), any in-memory modification of executable image will result in modification of the file on the disk. You don’t really want something like that to happen, do you??? At the same time, you don’t want the section to be treated as RO either, for understandable reasons - otherwise, all in-memory changes that you made to a page will be discarded when it gets swapped to the disk, so that the process address space will become just incoherent.
In order to deal with this dilemma, Cache Manager makes a distinction between executable section and data section - when pages that executable section is mapped to are swapped to the disk, they get flushed to the paging file, rather than to the one that backs up executable section (when it comes to data section, it gets flushed to the file that backs up the section).
Therefore, from the moment executable image gets loaded into RAM, the system does not really need the disk file that backs up executable image in order to run the process, so that it maintains file-process relationship information only for the statistical purposes. This is why file-process relationship information that you get is always the one that system had at the time of executable section creation - even if this info is already outdated…
Anton Bassov
Inline.
wrote in message news:xxxxx@ntdev…
>I am going to give you a bit more detailed explanation to the concepts
>behind David’s post…
>
> When you create a process, first of all, you open executable file, then
> create an executable section that is backed up by the file, and then call
> ZwCreateProcess() ( or ZwCreateProcessEx()) that, among other things,
> loads executable image into RAM. If memory pages of the target process
> don’t get accessed for a while or if the system is low on memory, they get
> swapped to the disk and are brought back to RAM when they get accessed.
>
I sure hope not and don’t think so. When an executable is loaded at process
start only the necessary pages are loaded. If relocations are required it
may need more memory than one that does not. If fixups are required
(relocation), then I think the pages are placed in the page file or fixups
are applied when it is reloaded. I don’t know what the logic is for the
various versions of Windows, but until the randomization of various
executable load addresses, the exe files are stripped of relocations. DLLs
would have them as it is fairly normal for them to be relocated.
> I hope by now you already see the potential problem here - if these pages
> are written to the original file (i.e. everything works the way it does
> with memory-mapped files), any in-memory modification of executable image
> will result in modification of the file on the disk. You don’t really want
> something like that to happen, do you??? At the same time, you don’t want
> the section to be treated as RO either, for understandable reasons -
> otherwise, all in-memory changes that you made to a page will be
> discarded when it gets swapped to the disk, so that the process address
> space will become just incoherent.
>
The OS does not write to executables when executing them. Even the data
segments are placed into the page file so an unmodified version is available
for executing in another process at any time.
> In order to deal with this dilemma, Cache Manager makes a distinction
> between executable section and data section - when pages that executable
> section is mapped to are swapped to the disk, they get flushed to the
> paging file, rather than to the one that backs up executable section (when
> it comes to data section, it gets flushed to the file that backs up the
> section).
>
>
> Therefore, from the moment executable image gets loaded into RAM, the
> system does not really need the disk file that backs up executable image
> in order to run the process, so that it maintains file-process
> relationship information only for the statistical purposes. This is why
> file-process relationship information that you get is always the one that
> system had at the time of executable section creation - even if this info
> is already outdated…
>
This is only true for drivers that don’t have resources that must be
available later. Drivers are loaded completely and then only pagable and
init sections are written to the page file or discarded, respectively. You
can overwrite a driver that is executing and have no problem as I have done
it many times. I think the error log resources are an exception when the
ErrorLog key is present in the registry and it refers to the driver that is
executing. Since a handle is opened to normal executable programs deleting
that program, if it can be done, doesn’t fully delete it and recover the
space until the last handle is closed. Yes, you can close that handle
yourself or by injection but I think it is a bad idea.
> Anton Bassov
>
Amit, you can get the most current path for an executable using NtQueryVirtualMemory. There is a function on PSAPI that uses precisely this. Note that this function does not work well for executables under W2K (although you can make it to work). It does work fine under XP and Vista.
> Amit, you can get the most current path for an executable using
NtQueryVirtualMemory.
Here is a 100%-UM solution.
Under the hood GetMappedFileName does call NtQueryVirtualMemory
with the 3rd parameter [MEMORY_INFORMATION_CLASS
MemoryInformationClass] equal to 2, which is
MemoryWorkingSetList (?).
// process_image.cpp
#include <windows.h>
#include <stdio.h>
#include <psapi.h>
#pragma comment(lib, “psapi”)
#define Elts(array) (sizeof(array) / sizeof(array[0]))
// Neither GetModuleFileNameExW nor GetProcessImageFileNameW
// report a change in EXE’s name/location; the trick below works:
int wmain(int argc, wchar_t* argv) {
int irc = 0;
ULONG iteration = 0;
wchar_t path2image[_MAX_PATH + 1];
_putws(L"Move or rename process_image.exe at some point in time:“);
do {
Sleep(1000);
printf(“iteration=%u\n”, ++iteration);
DWORD dwrc;
dwrc = GetMappedFileName(GetCurrentProcess(), (LPVOID)0x400000, path2image, Elts(path2image));
if(0 != dwrc) {
wprintf(L”\tpath2image=<%s>\n", path2image);
} else {
DWORD le = GetLastError();
wprintf(L"GetMappedFileName failed with le=%u=0x%x\n", le, le);
}
} while(true);
}
/
C:!ProjectsOnE_now_C\process_image\Debug>process_image.exe
Move or rename process_image.exe at some point in time:
iteration=1
path2image=<\Device\HarddiskVolume6!ProjectsOnE_now_C\process_image\Debug\process_image.exe>
. . .
iteration=13
path2image=<\Device\HarddiskVolume6!ProjectsOnE_now_C\process_image\Debug\process_image.exe>
// here I did “ren process_image.exe qqq.exe”:
iteration=14
path2image=<\Device\HarddiskVolume6!ProjectsOnE_now_C\process_image\Debug\qqq.exe>
. . .
iteration=17
path2image=<\Device\HarddiskVolume6!ProjectsOnE_now_C\process_image\Debug\qqq.exe>
// here I moved qqq.exe to C:\TEMP:
iteration=18
path2image=<\Device\HarddiskVolume6\TEMP\qqq.exe>
. . .
^C
C:!ProjectsOnE_now_C\process_image\Debug>
/
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-302460-
> xxxxx@lists.osr.com] On Behalf Of xxxxx@pandasecurity.com
> Sent: Sunday, October 07, 2007 5:20 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] How to find the path of executable if it is moved
> after running it?
>
> Amit, you can get the most current path for an executable using
> NtQueryVirtualMemory. There is a function on PSAPI that uses precisely
> this. Note that this function does not work well for executables under
> W2K (although you can make it to work). It does work fine under XP and
> Vista.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer</psapi.h></stdio.h></windows.h>
I believe the standard copy-on-write mechanism is what’s used to protect modified executable pages from being written back to the on-disk image. This is why choosing a good base address for a DLL is important - if the DLL has to be relocated at load time then a lot of pages have to be modified with the new base address, which results in a lot of copied-on-write pages and an increase in the private and therefore un-sharable portion of the process address space.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
Sent: Saturday, October 06, 2007 9:43 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to find the path of executable if it is moved after running it?
Inline.
wrote in message news:xxxxx@ntdev…
>I am going to give you a bit more detailed explanation to the concepts
>behind David’s post…
>
> When you create a process, first of all, you open executable file, then
> create an executable section that is backed up by the file, and then call
> ZwCreateProcess() ( or ZwCreateProcessEx()) that, among other things,
> loads executable image into RAM. If memory pages of the target process
> don’t get accessed for a while or if the system is low on memory, they get
> swapped to the disk and are brought back to RAM when they get accessed.
>
I sure hope not and don’t think so. When an executable is loaded at process
start only the necessary pages are loaded. If relocations are required it
may need more memory than one that does not. If fixups are required
(relocation), then I think the pages are placed in the page file or fixups
are applied when it is reloaded. I don’t know what the logic is for the
various versions of Windows, but until the randomization of various
executable load addresses, the exe files are stripped of relocations. DLLs
would have them as it is fairly normal for them to be relocated.
> I hope by now you already see the potential problem here - if these pages
> are written to the original file (i.e. everything works the way it does
> with memory-mapped files), any in-memory modification of executable image
> will result in modification of the file on the disk. You don’t really want
> something like that to happen, do you??? At the same time, you don’t want
> the section to be treated as RO either, for understandable reasons -
> otherwise, all in-memory changes that you made to a page will be
> discarded when it gets swapped to the disk, so that the process address
> space will become just incoherent.
>
The OS does not write to executables when executing them. Even the data
segments are placed into the page file so an unmodified version is available
for executing in another process at any time.
> In order to deal with this dilemma, Cache Manager makes a distinction
> between executable section and data section - when pages that executable
> section is mapped to are swapped to the disk, they get flushed to the
> paging file, rather than to the one that backs up executable section (when
> it comes to data section, it gets flushed to the file that backs up the
> section).
>
>
> Therefore, from the moment executable image gets loaded into RAM, the
> system does not really need the disk file that backs up executable image
> in order to run the process, so that it maintains file-process
> relationship information only for the statistical purposes. This is why
> file-process relationship information that you get is always the one that
> system had at the time of executable section creation - even if this info
> is already outdated…
>
This is only true for drivers that don’t have resources that must be
available later. Drivers are loaded completely and then only pagable and
init sections are written to the page file or discarded, respectively. You
can overwrite a driver that is executing and have no problem as I have done
it many times. I think the error log resources are an exception when the
ErrorLog key is present in the registry and it refers to the driver that is
executing. Since a handle is opened to normal executable programs deleting
that program, if it can be done, doesn’t fully delete it and recover the
space until the last handle is closed. Yes, you can close that handle
yourself or by injection but I think it is a bad idea.
> Anton Bassov
>
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Thanks to All,
Alex Shvedov, your is what I want.
This code is working well on XP onwords but I want it on 2K also.
GetMappedFileName() gives error 59 on 2K.
The path returned by GetMappedFileName() is \Device\HarddiskVolume1\Documents and Settings\Shrinivas\Desktop\MoveExePath.exe but I want it as c:\Documents and Settings\Shrinivas\Desktop\MoveExePath.exe.
What should I do?
Hi All,
According to my knowledge If we run any exe os uses it as memory mapped file.
Thus contents of file are buffered in main memory. Generally OS memory mappes code section of executable to the executing processes address space, and backed by same executable file. while data and noncode sections are backed by page file.
Now code sections is backed by same executable file and generally code does not changes so they didn’t become dirty and OS do not swap them to disk, instead content of pages are directly overwritten. And whenever these pages are refferenced they brought back to memory from executable file.
Thus OS dont allow us to delete or write file if it is executing in memory. But we can move it to some other place. I think this flexibility can be achived because memory mapped file refrences file object and not file path.
And I want that file path. Is there any way?
> This code is working well on XP onwords but I want it on 2K also.
… and this is why I included the hint on how NtQueryVirtualMemory
is called.
You may want to LoadLibrary/GetProcAddress for NtQueryVirtualMemory
and then call it in the same manner as GetMappedFileName does:
Look at the address2check also.
// process_image.cpp
#include <windows.h>
#include <stdio.h>
#include <ntsecapi.h> // for UNICODE_STRING
//#include <psapi.h>
//#pragma comment(lib, “psapi”)
#define Elts(array) (sizeof(array) / sizeof(array[0]))
typedef enum _MEMORY_INFORMATION_CLASS {
MemoryBasicInformation,
Something1,
Something2
} MEMORY_INFORMATION_CLASS, PMEMORY_INFORMATION_CLASS;
typedef LONG NTSTATUS;
#define OPTIONAL
//NTSYSAPI
typedef NTSTATUS (NTAPI NtQueryVirtualMemory_t)(
IN HANDLE ProcessHandle,
IN PVOID BaseAddress,
IN MEMORY_INFORMATION_CLASS MemoryInformationClass,
OUT PVOID Buffer,
IN ULONG Length,
OUT PULONG ResultLength OPTIONAL);
// Neither GetModuleFileNameExW nor GetProcessImageFileNameW
// report a change in EXE’s name/location; the trick below works:
int wmain(int argc, wchar_t argv[]) {
NtQueryVirtualMemory_t NtQueryVirtualMemory
= (NtQueryVirtualMemory_t)GetProcAddress(
GetModuleHandleA(“ntdll.dll”),
“NtQueryVirtualMemory”);
if(NULL == NtQueryVirtualMemory) {
return 1;
}
PVOID address2check = (PVOID)wmain;
ULONG iteration = 0;
wchar_t path2image[_MAX_PATH + 1];
_putws(L"Move or rename process_image.exe at some point in time:“);
do {
//DWORD dwrc;
//dwrc = GetMappedFileNameW(GetCurrentProcess(), (LPVOID)0x400000, path2image, Elts(path2image));
//if(0 != dwrc) {
// wprintf(L”\tpath2image=<%s>\n", path2image);
//} else {
// DWORD le = GetLastError();
// wprintf(L"GetMappedFileName failed with le=%u=0x%x\n", le, le);
//}
BYTE Buffer[530] = {0};
NTSTATUS status = NtQueryVirtualMemory(
(HANDLE)(UINT_PTR)0xFFFFFFFF,
//(PVOID)0x400000,
address2check,
Something2,
(PVOID)Buffer,
(ULONG)0x210,
(PULONG)NULL);
PUNICODE_STRING pImagePath = (PUNICODE_STRING)Buffer;
unsigned int ndx;
// extract wchars and …
for(ndx = 0; ndx < pImagePath->Length / sizeof(pImagePath->Buffer[0]); ++ndx) {
path2image[ndx] = pImagePath->Buffer[ndx];
}
// … add a terminator:
path2image[ndx] = 0;
wprintf(L"\tpath2image=<%s>\n", path2image);
Sleep(1000);
printf(“iteration=%u\n”, ++iteration);
} while(true);
return 0;
}
/
C:!ProjectsOnE_now_C\process_image\Debug>process_image.exe
Move or rename process_image.exe at some point in time:
iteration=1
path2image=<\Device\HarddiskVolume6!ProjectsOnE_now_C\process_image\Debug\process_image.exe>
. . .
iteration=13
path2image=<\Device\HarddiskVolume6!ProjectsOnE_now_C\process_image\Debug\process_image.exe>
// here I did “ren process_image.exe qqq.exe”:
iteration=14
path2image=<\Device\HarddiskVolume6!ProjectsOnE_now_C\process_image\Debug\qqq.exe>
. . .
iteration=17
path2image=<\Device\HarddiskVolume6!ProjectsOnE_now_C\process_image\Debug\qqq.exe>
// here I moved qqq.exe to C:\TEMP:
iteration=18
path2image=<\Device\HarddiskVolume6\TEMP\qqq.exe>
. . .
^C
C:!ProjectsOnE_now_C\process_image\Debug>
/
/
764F23C8 68 10 02 00 00 push 210h ; this is [internal] buffer length
764F23CD 8D 95 EC FD FF FF lea edx,[ebp-214h]
764F23D3 52 push edx ; this is buffer address
764F23D4 6A 02 push 2 ; this is MEMORY_INFORMATION_CLASS MemoryInformationClass
764F23D6 51 push ecx ; this is 0x400000 - address to check
764F23D7 50 push eax ;l this is 0xFFFFFFFF - pseudo-handle to current process
764F23D8 FF 15 10 10 4F 76 call dword ptr [imp NtQueryVirtualMemory@24 (764F1010h)]
*/
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-302474-
> xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
> Sent: Monday, October 08, 2007 12:32 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] How to find the path of executable if it is moved
> after running it?
>
> Thanks to All,
>
> Alex Shvedov, your is what I want.
>
> This code is working well on XP onwords but I want it on 2K also.
>
> GetMappedFileName() gives error 59 on 2K.
>
> The path returned by GetMappedFileName() is
> \Device\HarddiskVolume1\Documents and
> Settings\Shrinivas\Desktop\MoveExePath.exe but I want it as
> c:\Documents and Settings\Shrinivas\Desktop\MoveExePath.exe.
>
> What should I do?
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer</psapi.h></ntsecapi.h></stdio.h></windows.h>
Please note that the error you get when calling GetMappedFileName with an executable image, under W2K, comes from NtQueryVirtualMemory itself, not from the function GetMappedFileName.
Within the function NtQueryVirtualMemory, subfunction MemorySectionName, under W2K, there is code that looks like follows:
IF(SectionType == IMAGE_FILE) THEN Return ERROR_XX
So if the section is an executable image (like an EXE or DLL) it wont work.
For some reason the coders of this routine decided that it was not useful/suitable to get the name of an executable image using this function.
However if you want to check that actually it would work, follow carefuly the code of this routine from within your debugger and skip the ‘IF’ sentence. You will find that you actually get the image name.
Of course, the IF sentence above described is not present under XP or Vista.
Inaki.
> When an executable is loaded at process start only the necessary pages are
loaded.
Exactly. Page fault handler is responsible for maintaining virtual to
physical mapping using information from the VAD tree.
This is a common concept in OS theory.
–
Slava Imameyev, xxxxx@hotmail.com
“David J. Craig” wrote in message
news:xxxxx@ntdev…
> Inline.
>
> wrote in message news:xxxxx@ntdev…
>>I am going to give you a bit more detailed explanation to the concepts
>>behind David’s post…
>>
>> When you create a process, first of all, you open executable file, then
>> create an executable section that is backed up by the file, and then call
>> ZwCreateProcess() ( or ZwCreateProcessEx()) that, among other things,
>> loads executable image into RAM. If memory pages of the target process
>> don’t get accessed for a while or if the system is low on memory, they
>> get swapped to the disk and are brought back to RAM when they get
>> accessed.
>>
> I sure hope not and don’t think so. When an executable is loaded at
> process start only the necessary pages are loaded. If relocations are
> required it may need more memory than one that does not. If fixups are
> required (relocation), then I think the pages are placed in the page file
> or fixups are applied when it is reloaded. I don’t know what the logic is
> for the various versions of Windows, but until the randomization of
> various executable load addresses, the exe files are stripped of
> relocations. DLLs would have them as it is fairly normal for them to be
> relocated.
>
>> I hope by now you already see the potential problem here - if these pages
>> are written to the original file (i.e. everything works the way it does
>> with memory-mapped files), any in-memory modification of executable
>> image will result in modification of the file on the disk. You don’t
>> really want something like that to happen, do you??? At the same time,
>> you don’t want the section to be treated as RO either, for understandable
>> reasons - otherwise, all in-memory changes that you made to a page will
>> be discarded when it gets swapped to the disk, so that the process
>> address space will become just incoherent.
>>
> The OS does not write to executables when executing them. Even the data
> segments are placed into the page file so an unmodified version is
> available for executing in another process at any time.
>
>> In order to deal with this dilemma, Cache Manager makes a distinction
>> between executable section and data section - when pages that executable
>> section is mapped to are swapped to the disk, they get flushed to the
>> paging file, rather than to the one that backs up executable section
>> (when it comes to data section, it gets flushed to the file that backs up
>> the section).
>>
>>
>> Therefore, from the moment executable image gets loaded into RAM, the
>> system does not really need the disk file that backs up executable image
>> in order to run the process, so that it maintains file-process
>> relationship information only for the statistical purposes. This is why
>> file-process relationship information that you get is always the one that
>> system had at the time of executable section creation - even if this
>> info is already outdated…
>>
> This is only true for drivers that don’t have resources that must be
> available later. Drivers are loaded completely and then only pagable and
> init sections are written to the page file or discarded, respectively.
> You can overwrite a driver that is executing and have no problem as I have
> done it many times. I think the error log resources are an exception when
> the ErrorLog key is present in the registry and it refers to the driver
> that is executing. Since a handle is opened to normal executable programs
> deleting that program, if it can be done, doesn’t fully delete it and
> recover the space until the last handle is closed. Yes, you can close
> that handle yourself or by injection but I think it is a bad idea.
>
>> Anton Bassov
>>
>
>
>
> Therefore, from the moment executable image gets loaded into RAM, the
system does not really need the disk file that backs up executable image
I think this is wrong for user-mode sections. Segment object for executable
section is backed by the executable file.
any in-memory modification of executable image will result in modification
of the file on the disk.
The COW( Copy-On-Write ) deals with this. The private copy of a page is
created. This is common for nearly all OSes.
In order to deal with this dilemma, Cache Manager makes a distinction
between executable section and data section - when pages that executable
section is mapped to are swapped to the disk, they get flushed to the
paging file
Only private ( COW pages, see above ) are backed by the page file. Also,
Cache Manager has nothing to do with executable sections, it works with data
sections.
–
Slava Imameyev, xxxxx@hotmail.com
wrote in message news:xxxxx@ntdev…
>I am going to give you a bit more detailed explanation to the concepts
>behind David’s post…
>
> When you create a process, first of all, you open executable file, then
> create an executable section that is backed up by the file, and then call
> ZwCreateProcess() ( or ZwCreateProcessEx()) that, among other things,
> loads executable image into RAM. If memory pages of the target process
> don’t get accessed for a while or if the system is low on memory, they get
> swapped to the disk and are brought back to RAM when they get accessed.
>
> I hope by now you already see the potential problem here - if these pages
> are written to the original file (i.e. everything works the way it does
> with memory-mapped files), any in-memory modification of executable image
> will result in modification of the file on the disk. You don’t really want
> something like that to happen, do you??? At the same time, you don’t want
> the section to be treated as RO either, for understandable reasons -
> otherwise, all in-memory changes that you made to a page will be
> discarded when it gets swapped to the disk, so that the process address
> space will become just incoherent.
>
> In order to deal with this dilemma, Cache Manager makes a distinction
> between executable section and data section - when pages that executable
> section is mapped to are swapped to the disk, they get flushed to the
> paging file, rather than to the one that backs up executable section (when
> it comes to data section, it gets flushed to the file that backs up the
> section).
>
>
> Therefore, from the moment executable image gets loaded into RAM, the
> system does not really need the disk file that backs up executable image
> in order to run the process, so that it maintains file-process
> relationship information only for the statistical purposes. This is why
> file-process relationship information that you get is always the one that
> system had at the time of executable section creation - even if this info
> is already outdated…
>
> Anton Bassov
>
> IF(SectionType == IMAGE_FILE) THEN Return ERROR_XX
Well, I left something for the OP to code:-)
I did not try it below Vista, it’s the idea, not a production code.
A pro po, that _MAX_PATH + 1 thing is my bug for at least 2 reasons.
-------------- Original message --------------
From: Iñaki Castillo
> Please note that the error you get when calling GetMappedFileName with an
> executable image, under W2K, comes from NtQueryVirtualMemory itself, not from
> the function GetMappedFileName.
>
> Within the function NtQueryVirtualMemory, subfunction MemorySectionName, under
> W2K, there is code that looks like follows:
>
> IF(SectionType == IMAGE_FILE) THEN Return ERROR_XX
>
> So if the section is an executable image (like an EXE or DLL) it wont work.
> For some reason the coders of this routine decided that it was not
> useful/suitable to get the name of an executable image using this function.
>
> However if you want to check that actually it would work, follow carefuly the
> code of this routine from within your debugger and skip the ‘IF’ sentence. You
> will find that you actually get the image name.
>
> Of course, the IF sentence above described is not present under XP or Vista.
>
>
> Inaki.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>why choosing a good base address for a DLL is important - if the DLL has to be
relocated at load time then a lot of pages have to be modified with the new
base
address, which results in a lot of copied-on-write pages and an increase in
the
private and therefore un-sharable portion of the process address space.
I have a hope that AOL ICQ messenger developers are reading this 
they have
around 50 DLLs with the same default base address.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Only private ( COW pages, see above ) are backed by the page file. Also,
Cache Manager has nothing to do with executable sections, it works with data
sections.
It works with cache maps, which in turn are based on Mm’s data control areas
(sections).
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Probably GetMappedFileName on w2k works for data files only, not for
executable images.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Thanks to All,
>
> Alex Shvedov, your is what I want.
>
> This code is working well on XP onwords but I want it on 2K also.
>
> GetMappedFileName() gives error 59 on 2K.
>
> The path returned by GetMappedFileName() is \Device\HarddiskVolume1\Documents
and Settings\Shrinivas\Desktop\MoveExePath.exe but I want it as c:\Documents
and Settings\Shrinivas\Desktop\MoveExePath.exe.
>
> What should I do?
>
>
> The path returned by GetMappedFileName() is
\Device\HarddiskVolume1\Documents
and Settings\Shrinivas\Desktop\MoveExePath.exe but I want it as
c:\Documents
and Settings\Shrinivas\Desktop\MoveExePath.exe.What should I do?
Read the archives:-)
If this is your only problem, you’re lucky.
One of the (approx. 1,000,000) ways is stupid search: go through all possible
DosDeviceName results and compare what is spits out with the prefix of what
GMFN (or NtXYZ) returns.
This is stupid but good enough: the number of combinations - and therefore
time expense - is negligible, but the result is linked to a session, this
is important (what is your C: may well be D: for another user, see what
I mean?)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-302557-
xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Monday, October 08, 2007 9:02 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to find the path of executable if it is moved
after running it?Probably GetMappedFileName on w2k works for data files only, not
for
executable images.–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.comwrote in message news:xxxxx@ntdev…
> > Thanks to All,
> >
> > Alex Shvedov, your is what I want.
> >
> > This code is working well on XP onwords but I want it on 2K also.
> >
> > GetMappedFileName() gives error 59 on 2K.
> >
> > The path returned by GetMappedFileName() is
> \Device\HarddiskVolume1\Documents
> and Settings\Shrinivas\Desktop\MoveExePath.exe but I want it as
> c:\Documents
> and Settings\Shrinivas\Desktop\MoveExePath.exe.
> >
> > What should I do?
> >
> >
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer