Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Writing WDF Drivers: Core Concepts Lab, Boston/Waltham, MA 22-26 September, 2014
Windows Internals & Software Drivers Lab, Dulles/Sterling, VA, 20-24 October, 2014
Developing File Systems for Windows, Seattle, WA 4-7 November, 2014


Go Back   OSR Online Lists > ntfsd
Welcome, Guest
You must login to post to this list
  Message 1 of 30  
28 May 09 05:25
ntfsd member 42967
xxxxxx@yahoo.com
Join Date:
Posts To This List: 21
Processname from PEProcess

Hi, How do I get the process name from an available PEProcess ? I looked through the forum history but got confused!! Also, Documentation says zwQueryInformationProcess is not to be used!! Regards, Prasad
  Message 2 of 30  
28 May 09 12:01
Ken Johnson
xxxxxx@valhallalegends.com
Join Date: 24 Jul 2008
Posts To This List: 227
Processname from PEProcess

Why do you think that you need to do this? Process name is not a reliable way to identify processes uniquely nor authoritatively. - S -----Original Message----- From: xxxxx@yahoo.com <xxxxx@yahoo.com> Sent: Thursday, May 28, 2009 02:25 To: Windows File Systems Devs Interest List <xxxxx@lists.osr.com> Subject: [ntfsd] Processname from PEProcess Hi, How do I get the process name from an available PEProcess ? I looked through the forum history but got confused!! Also, Documentation says zwQueryInformationProcess is not to be used!! Regards, Prasad --- NTFSD is sponsored by OSR For our schedule of debugging and file system seminars (including our new fs mini-filter seminar) 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
  Message 3 of 30  
28 May 09 12:19
ntfsd member 40402
xxxxxx@gmail.com
Join Date:
Posts To This List: 2
Processname from PEProcess

Hi The process name offset can be founded form peprocess but you should write a simple code. First of all call PsGetCurrentProcess() to achieve the address of peprocess of current process then search for the string "System" in the increasing offsets form peprocess. If you find "System " string , the related offset is the name offset. Cheers Shabnam Aboughadareh On Thu, May 28, 2009 at 1:26 AM, <xxxxx@yahoo.com> wrote: > Hi, > > How do I get the process name from an available PEProcess ? > > I looked through the forum history but got confused!! > Also, Documentation says zwQueryInformationProcess is not to be used!! > > Regards, > Prasad > <...excess quoted lines suppressed...> --
  Message 4 of 30  
28 May 09 12:26
Don Burn
xxxxxx@acm.org
Join Date:
Posts To This List: 941
Processname from PEProcess

That works for some systems but not all, since they changed the PEPROCESS structure. Why in the world would you want this, it can be arbitrarily set to anything one wants, it is just by default that it is the executable name. The OP needs to tell us why he thinks this is something he needs, and why he cannot go to user space and get it with well known methods -- Don Burn (MVP, Windows DDK) Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr "shabnam abooghadare" <xxxxx@gmail.com> wrote in message news:82919@ntfsd... > Hi > > The process name offset can be founded form peprocess but you should write > a > simple code. > First of all call PsGetCurrentProcess() to achieve the address of > peprocess > of current process then search for the string "System" in the increasing > offsets form peprocess. > If you find "System " string , the related offset is the name offset. <...excess quoted lines suppressed...> __________ Information from ESET NOD32 Antivirus, version of virus signature database 4112 (20090528) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
  Message 5 of 30  
28 May 09 12:46
Ken Johnson
xxxxxx@valhallalegends.com
Join Date: 24 Jul 2008
Posts To This List: 227
Processname from PEProcess

Please do not attempt to do this. It's completely fragile and subject to breaking at any time. Instead, the OP needs to specify what they're trying to do at heart here, so that a properly engineered solution can be applied. - S ________________________________ From: shabnam abooghadare <xxxxx@gmail.com> Sent: Thursday, May 28, 2009 09:19 To: Windows File Systems Devs Interest List <xxxxx@lists.osr.com> Subject: Re: [ntfsd] Processname from PEProcess Hi The process name offset can be founded form peprocess but you should write a simple code. First of all call PsGetCurrentProcess() to achieve the address of peprocess of current process then search for the string "System" in the increasing offsets form peprocess. If you find "System " string , the related offset is the name offset. Cheers Shabnam Aboughadareh On Thu, May 28, 2009 at 1:26 AM, <xxxxx@yahoo.com<mailto:xxxxx@yahoo.com>> wrote: Hi, How do I get the process name from an available PEProcess ? I looked through the forum history but got confused!! Also, Documentation says zwQueryInformationProcess is not to be used!! Regards, Prasad --- NTFSD is sponsored by OSR For our schedule of debugging and file system seminars (including our new fs mini-filter seminar) 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 --- NTFSD is sponsored by OSR For our schedule of debugging and file system seminars (including our new fs mini-filter seminar) 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 --
  Message 6 of 30  
28 May 09 13:23
Alex Shvedov
xxxxxx@comcast.net
Join Date: 10 Mar 2006
Posts To This List: 112
Processname from PEProcess

> It's completely fragile and subject to breaking at any time. This is what filemon did years ago. It was never good, and then (_then_) it worked. ----- Original Message ----- From: Skywing To: Windows File Systems Devs Interest List Sent: Thursday, May 28, 2009 12:45 PM Subject: RE: [ntfsd] Processname from PEProcess Please do not attempt to do this. It's completely fragile and subject to breaking at any time. Instead, the OP needs to specify what they're trying to do at heart here, so that a properly engineered solution can be applied. - S ------------------------------------------------------------------------------ From: shabnam abooghadare <xxxxx@gmail.com> Sent: Thursday, May 28, 2009 09:19 To: Windows File Systems Devs Interest List <xxxxx@lists.osr.com> Subject: Re: [ntfsd] Processname from PEProcess Hi The process name offset can be founded form peprocess but you should write a simple code. First of all call PsGetCurrentProcess() to achieve the address of peprocess of current process then search for the string "System" in the increasing offsets form peprocess. If you find "System " string , the related offset is the name offset. Cheers Shabnam Aboughadareh On Thu, May 28, 2009 at 1:26 AM, <xxxxx@yahoo.com> wrote: Hi, How do I get the process name from an available PEProcess ? I looked through the forum history but got confused!! Also, Documentation says zwQueryInformationProcess is not to be used!! Regards, Prasad --- NTFSD is sponsored by OSR For our schedule of debugging and file system seminars (including our new fs mini-filter seminar) 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 --- NTFSD is sponsored by OSR For our schedule of debugging and file system seminars (including our new fs mini-filter seminar) 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 --- NTFSD is sponsored by OSR For our schedule of debugging and file system seminars (including our new fs mini-filter seminar) 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 --
  Message 7 of 30  
28 May 09 15:41
Tony Mason
xxxxxx@osr.com
Join Date:
Posts To This List: 2511
List Moderator
Processname from PEProcess

Sigh. I think I must have wasted my time. http://www.osronline.com/article.cfm?article=472 This article describes how to do this (on XP and more recent) and even went through a review process with the filter manager team folks at the time. Please never use undocumented fields in the EPROCESS. Tony OSR --
  Message 8 of 30  
29 May 09 09:38
Aditya Shrivastava
xxxxxx@gmail.com
Join Date: 05 Oct 2006
Posts To This List: 412
Processname from PEProcess

>>The process name offset can be founded form peprocess but you should write a simple code. Why not do it straight, windbg kernel debugging dt _EPROCESS, see ImageFileName This method will NOT give the complete executable name as the name field is just 16 bytes long, So you'll miss characters if the name is more than 16 char long. Why can't you do it from user mode? Aditya
  Message 9 of 30  
29 May 09 09:41
Don Burn
xxxxxx@acm.org
Join Date:
Posts To This List: 941
Processname from PEProcess

No, it will give the process name not the executable name, it just turns out by default that Windows makes this the same, but it can be set differently! As far as using it for the offset, that works for exactly that version of the kernel, so the guys driver is still broken. -- Don Burn (MVP, Windows DDK) Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr <xxxxx@gmail.com> wrote in message news:82939@ntfsd... >>>The process name offset can be founded form peprocess but you should >>>write a simple code. > > Why not do it straight, > > windbg kernel debugging > > dt _EPROCESS, see ImageFileName > > This method will NOT give the complete executable name as the name field <...excess quoted lines suppressed...> __________ Information from ESET NOD32 Antivirus, version of virus signature database 4115 (20090529) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
  Message 10 of 30  
29 May 09 10:02
Aditya Shrivastava
xxxxxx@gmail.com
Join Date: 05 Oct 2006
Posts To This List: 412
Processname from PEProcess

>>No, it will give the process name not the executable name, it just turns out by default that Windows makes this the same, but it can be set differently! Got it, actually OP states that "process name from PE", but what you said is yes, exactly correct. >>As far as using it for the offset, that works for exactly that version of the kernel, so the guys driver is still broken. I understand this, we relied on this for a product and ended up with conditional compilation for each OS, it did not trouble us a lot because we were anyhow needing a lot of kernel specific information and had to develop our application tightly coupled with the OS version as it was a requirement. but again the app was intended for a specific research community inside the organization and was not a commercial product. So what you said is perfectly sensible for any other driver. Thanks Aditya
  Message 11 of 30  
29 May 09 10:16
Eric Diven
xxxxxx@edsiohio.com
Join Date: 24 Jul 2007
Posts To This List: 321
Processname from PEProcess

> >>The process name offset can be founded form peprocess but > you should write a simple code. > > Why not do it straight, > > windbg kernel debugging > > dt _EPROCESS, see ImageFileName > Because you can do it on the fly on the running system, and not have to have conditional compilation for different kernel versions. I'm not proposing that the OP actually does this, just pointing out that it's possible. Of course it assumes that the name of the "System" process remains constant. ~Eric
  Message 12 of 30  
29 May 09 10:22
Don Burn
xxxxxx@acm.org
Join Date:
Posts To This List: 941
Processname from PEProcess

And this is a piece of crap since in the past depending on the system the entry in the EPROCESS structure was either a UNICODE_STRING or a PUNICODE_STRING. Using this type of garbage code just destabilizes systems, it is unfortunate that way too many people took Russinovich's code which was for experiment only, and started using techniques from it in production drivers. For those who have stated they use this technique in their products, I ask the standard please let us know what these products are so we can avoid them and get out customers to do the same. -- Don Burn (MVP, Windows DDK) Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr "Eric Diven" <xxxxx@edsiohio.com> wrote in message news:82948@ntfsd... > >>The process name offset can be founded form peprocess but > you should write a simple code. > > Why not do it straight, > > windbg kernel debugging > > dt _EPROCESS, see ImageFileName > Because you can do it on the fly on the running system, and not have to have conditional compilation for different kernel versions. I'm not proposing that the OP actually does this, just pointing out that it's possible. Of course it assumes that the name of the "System" process remains constant. ~Eric __________ Information from ESET NOD32 Antivirus, version of virus signature database 4115 (20090529) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 4115 (20090529) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
  Message 13 of 30  
29 May 09 10:35
Eric Diven
xxxxxx@edsiohio.com
Join Date: 24 Jul 2007
Posts To This List: 321
Processname from PEProcess

Of course it's a piece of crap and shouldn't be used in production code. At this point Tony has posted the correct solution, and we're just discussing the merits (or lack thereof) of the various wrong ways to do it. Also, in Tony's article, he calls out the undocumented PsGetProcessImageFileName function, which would also be a questionable approach, but at least presumably knows the internals of the EPROCESS struct well enough to not go traipsing through memory looking for a non-existant string until it causes an access violation. Incidentally, the code in the article uses NtCurrentProcess instead of ZwCurrentProcess. Is there a reason for that? ~Eric > -----Original Message----- > From: xxxxx@lists.osr.com > [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn > Sent: Friday, May 29, 2009 10:22 AM > To: Windows File Systems Devs Interest List > Subject: Re:[ntfsd] Processname from PEProcess > > And this is a piece of crap since in the past depending on > the system the entry in the EPROCESS structure was either a > UNICODE_STRING or a <...excess quoted lines suppressed...>
  Message 14 of 30  
29 May 09 11:05
ntfsd member 19759
xxxxxx@evitechnology.com
Join Date:
Posts To This List: 359
Processname from PEProcess

That article predates the information about MmGetSystemRoutineAddress() on certain platforms. Frankly, I don't remember the details of the implications of MMGSRA() on the affected platforms, so the check for NULL be all you need to prevent crashing in the degenerate cases, which may not even include 'ZwQueryInformationProcess()' anyway; I don't know. Just thought I'd mention it. mm
  Message 15 of 30  
29 May 09 11:12
ntfsd member 32706
xxxxxx@gmail.com
Join Date:
Posts To This List: 10
Processname from PEProcess

Following a Guru's path, who is beaten down, worn out, weathered almost all odds is as pragmatic as one could get, IMHO. I just looked at the article, and already covered a lot of gottaches, so enhancing along that road to support couple version of OSes should not be that much of a problem... -pro On Fri, May 29, 2009 at 7:34 AM, Eric Diven <xxxxx@edsiohio.com> wrote: > Of course it's a piece of crap and shouldn't be used in production code. > At this point Tony has posted the correct solution, and we're just > discussing the merits (or lack thereof) of the various wrong ways to do > it. > > Also, in Tony's article, he calls out the undocumented > PsGetProcessImageFileName function, which would also be a questionable > approach, but at least presumably knows the internals of the EPROCESS > struct well enough to not go traipsing through memory looking for a > non-existant string until it causes an access violation. <...excess quoted lines suppressed...> --
  Message 16 of 30  
29 May 09 11:19
Scott Noone
xxxxxx@osr.com
Join Date: 10 Jul 2002
Posts To This List: 683
List Moderator
Processname from PEProcess

>Incidentally, the code in the article uses NtCurrentProcess instead of >ZwCurrentProcess. Is there a reason for that? #define NtCurrentProcess() ( (HANDLE)(LONG_PTR) -1 ) #define ZwCurrentProcess() NtCurrentProcess() #define NtCurrentThread() ( (HANDLE)(LONG_PTR) -2 ) #define ZwCurrentThread() NtCurrentThread() The Zw ones are a relatively new addition (S03 maybe?) and pretty amusing. Really beating that, "don't call NtXxx APIs in kernel mode" drum. -scott -- Scott Noone Consulting Associate OSR Open Systems Resources, Inc. http://www.osronline.com "Eric Diven" <xxxxx@edsiohio.com> wrote in message news:82951@ntfsd... Of course it's a piece of crap and shouldn't be used in production code. At this point Tony has posted the correct solution, and we're just discussing the merits (or lack thereof) of the various wrong ways to do it. Also, in Tony's article, he calls out the undocumented PsGetProcessImageFileName function, which would also be a questionable approach, but at least presumably knows the internals of the EPROCESS struct well enough to not go traipsing through memory looking for a non-existant string until it causes an access violation. Incidentally, the code in the article uses NtCurrentProcess instead of ZwCurrentProcess. Is there a reason for that? ~Eric > -----Original Message----- > From: xxxxx@lists.osr.com > [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn > Sent: Friday, May 29, 2009 10:22 AM > To: Windows File Systems Devs Interest List > Subject: Re:[ntfsd] Processname from PEProcess > > And this is a piece of crap since in the past depending on > the system the entry in the EPROCESS structure was either a > UNICODE_STRING or a <...excess quoted lines suppressed...>
  Message 17 of 30  
29 May 09 11:41
Tony Mason
xxxxxx@osr.com
Join Date:
Posts To This List: 2511
List Moderator
Processname from PEProcess

To answer Eric's question: I'm old. A long time ago the only thing defined was NtCurrentProcess. Now we have both variants. Lest you think any of this matters: #define NtCurrentProcess() ( (HANDLE)(LONG_PTR) -1 ) #define ZwCurrentProcess() NtCurrentProcess() #define NtCurrentThread() ( (HANDLE)(LONG_PTR) -2 ) #define ZwCurrentThread() NtCurrentThread() (from my 6001 WDK.) Tony
  Message 18 of 30  
29 May 09 18:20
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 289
List Moderator
Processname from PEProcess

<QUOTE> Really beating that, "don't call NtXxx APIs in kernel mode" drum. </QUOTE> Which is, on its face, a very poor guideline. The actual guideline should be "Understand well the difference between the Zw and Nt variant of the system service, and call the one you actually need... and if you don't know any better, use the Zw version." If nothing in kernel-mode ever needed to call the Nt variant, it wouldn't be necessary to include it in the operating system. (Sorry, I just HATE overly simplistic rules) Peter OSR (WOW... 3 OSR posts in a row)
  Message 19 of 30  
29 May 09 19:14
Ken Johnson
xxxxxx@valhallalegends.com
Join Date: 24 Jul 2008
Posts To This List: 227
Processname from PEProcess

Can you provide a concrete example of when you would need to use an Nt varians? Are you just trying to shave a few cycles off of a tight system call loop in a system thread? These are of course included with the OS as the underlying implementation lives there today. - S -----Original Message----- From: xxxxx@osr.com <xxxxx@osr.com> Sent: Friday, May 29, 2009 15:20 To: Windows File Systems Devs Interest List <xxxxx@lists.osr.com> Subject: RE:[ntfsd] Processname from PEProcess <QUOTE> Really beating that, "don't call NtXxx APIs in kernel mode" drum. </QUOTE> Which is, on its face, a very poor guideline. The actual guideline should be "Understand well the difference between the Zw and Nt variant of the system service, and call the one you actually need... and if you don't know any better, use the Zw version." If nothing in kernel-mode ever needed to call the Nt variant, it wouldn't be necessary to include it in the operating system. (Sorry, I just HATE overly simplistic rules) Peter OSR (WOW... 3 OSR posts in a row) --- NTFSD is sponsored by OSR For our schedule of debugging and file system seminars (including our new fs mini-filter seminar) 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
  Message 20 of 30  
29 May 09 19:50
Tony Mason
xxxxxx@osr.com
Join Date:
Posts To This List: 2511
List Moderator
Processname from PEProcess

Concrete example: some file system APIs require they be invoked from UserMode; a kernel mode invocation fails. Thus, if you call the Zw variant, the call fails. The first time I saw this I recall that it was a bit painful (we ended up allocating user address space buffers so we could pass them into the call.) More general case: Sometimes I am performing operations using user provided buffers and/or parameters. If I call the Zw variant, I have to do all the buffer handling. If I call the Nt variant, I can live comfortably knowing the correct parameter checking is being done. Tony OSR
  Message 21 of 30  
30 May 09 03:34
Daniel Terhell
xxxxxx@resplendence.com
Join Date: 14 Apr 2004
Posts To This List: 372
Processname from PEProcess

Sorry Don, both of these are false. At least since NT4 this has been a NULL terminated ansi string and the technique Russinovich used is to scan for the offset in DriverEntry when you find yourself in the system process context. So these names can be altered but does this not hold for all other methods as well ? This method at least has worked on all versions of Windows I have seen. Of course this is hacking away into undocumented structures and plain evil but the alternative mentioned NtQueryInformationProcess is documented for usermode only and includes the warning "may be altered or unavailable in future versions of Windows". According to my standards this is equally bad practice. So for me the root of the problem is that there are no documented interfaces for querying process names in the kernel. All this of course because they know what's best for us, just as if the only possible purpose to know a process name is to use it as a criteria to make decisions for a security product. //Daniel "Don Burn" <xxxxx@acm.org> wrote in message news:82940@ntfsd... > No, it will give the process name not the executable name, it just turns > out by default that Windows makes this the same, but it can be set > differently! As far as using it for the offset, that works for exactly > that version of the kernel, so the guys driver is still broken. > .... >And this is a piece of crap since in the past depending on the system the >entry in the EPROCESS structure was either a UNICODE_STRING or a >PUNICODE_STRING
  Message 22 of 30  
30 May 09 04:17
David J. Craig
xxxxxx@yoshimuni.com
Join Date:
Posts To This List: 683
Processname from PEProcess

I don't use it, but I do disagree with your take on the idea of using NtQueryInformationProcess(). If it is documented for a specific OS version, you can limit your usage of that query to those listed as supported, but not have it run on an OS version newer than documented until you have a chance to verify it still works and is documented. I think that caveat is to allow Microsoft to change it without anyone being able to say it broke some form of 'contract'. I do agree that using it for security purposes is not a good idea. Only digital signatures verifiable from a trusted source can give you a chance of security. Even with that using process injection and many other techniques can compromise almost all attempts to secure an OS where the user has admin rights. <xxxxx@resplendence.com> wrote in message news:82964@ntfsd... > Sorry Don, both of these are false. At least since NT4 this has been a > NULL terminated ansi string and the technique Russinovich used is to scan > for the offset in DriverEntry when you find yourself in the system process > context. So these names can be altered but does this not hold for all > other methods as well ? This method at least has worked on all versions of > Windows I have seen. > > Of course this is hacking away into undocumented structures and plain evil > but the alternative mentioned NtQueryInformationProcess is documented for > usermode only and includes the warning "may be altered or unavailable in <...excess quoted lines suppressed...>
  Message 23 of 30  
30 May 09 04:27
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 23 Feb 2000
Posts To This List: 4098
Processname from PEProcess

> Sorry Don, both of these are false. At least since NT4 this has been a NULL > terminated ansi string and the technique Russinovich used is to scan for the > offset in DriverEntry when you find yourself in the system process context. More so - this is the string Task Manager shows, it gets it by ZwQueryInformationProcess I think. This string is truncated to IIRC 13 chars, and is not a full pathname. -- Maxim S. Shatskih Windows DDK MVP xxxxx@storagecraft.com http://www.storagecraft.com
  Message 24 of 30  
30 May 09 04:32
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 23 Feb 2000
Posts To This List: 4098
Processname from PEProcess

>variant, the call fails. The first time I saw this I recall that it was >a bit painful (we ended up allocating user address space buffers so we >could pass them into the call.) For instance, FSCTL_GET_VOLUME_BITMAP on NT4. -- Maxim S. Shatskih Windows DDK MVP xxxxx@storagecraft.com http://www.storagecraft.com
  Message 25 of 30  
30 May 09 08:31
Bo Brantén
xxxxxx@acc.umu.se
Join Date:
Posts To This List: 45
Processname from PEProcess

On Sat, 30 May 2009, Maxim S. Shatskih wrote: > This string is truncated to IIRC 13 chars, and is not a full pathname. It is possible to get the full path from the undocumented structures that is available, below is two messages that has been posted before to this list that shows how to do it: RH> Hello! RH> How can I get the full pathname for the process which requested current RH> IRP? I currently receive the process name (as in FileMon sample), but I RH> don't want "iexplore.exe". I want the full path name: "C:\Program RH> Files\Internet Explorer\iexplore.exe". RH> Anyone knows how this can be done? RH> Best wishes, RH> Razvan Hobeanu try that. I did that and it works ------------------------------------------------------- typedef struct _RTL_USER_PROCESS_PARAMETERS { UCHAR dummy[0x38]; //ñìåùåíèå â ïàðàìåòðå 0x38 - ïðîöåññ, çàïóñòèâøèé ýòîò UNICODE_STRING ImagePathName; } RTL_USER_PROCESS_PARAMETERS, *PRTL_USER_PROCESS_PARAMETERS; #define SYSNAME "System" ULONG FileSpyGetProcessNameOffset( VOID) { PEPROCESS curproc; int i; //NTSTATUS Status = STATUS_SUCCESS; curproc = PsGetCurrentProcess(); // Scan for 12KB, hoping the KPEB never grows that big! // for( i = 0; i < 3*PAGE_SIZE; i++ ) { if( !strncmp( SYSNAME, (PCHAR) curproc + i, strlen(SYSNAME) )) { return i; } } // // Name not found - oh, well // return 0; } ProcessNameOffset = FileSpyGetProcessNameOffset(); PCHAR GetPathImageProcess( PCHAR PathImage ) { PEPROCESS curproc; char *nameptr; DWORD dw = 0; LPDWORD tdw; ANSI_STRING ansi; NTSTATUS ntStatus; PRTL_USER_PROCESS_PARAMETERS pupp = NULL; if( ProcessNameOffset ) { curproc = PsGetCurrentProcess(); //nameptr = (PCHAR) curproc + ProcessNameOffset; //+0x1DC //ÄËß NT 4 if( 476==ProcessNameOffset ) { tdw = (LPDWORD)(((PCHAR)curproc)+0x18C); //??? 18C dw = *tdw; //_PEB tdw = (LPDWORD)((PCHAR)dw+0x10); dw = *tdw; //ProcessParameters tdw = (LPDWORD)((PCHAR)dw + 0x0); dw = *tdw; } else { //ÄËß WIN 2000 tdw = (LPDWORD)(((PCHAR)curproc)+0x1B0); //??? dw = *tdw; //_PEB 0x7ffdf000 tdw = (LPDWORD)((PCHAR)dw+0x10); dw = *tdw; tdw = (LPDWORD)((PCHAR)dw + 0x0); dw = *tdw; } //ïðèâåëè ó÷àñòîê ïàìÿòè ê äàííîé ñòðóêòóðå pupp = (PRTL_USER_PROCESS_PARAMETERS)(tdw); ntStatus = RtlUnicodeStringToAnsiString( &ansi, &pupp->ImagePathName, TRUE); if( ntStatus==STATUS_SUCCESS ) { dw = ansi.Length; if( dw > 2045 ) dw = 2045; memcpy( PathImage, ansi.Buffer, dw ); PathImage[dw] = 0; RtlFreeAnsiString( &ansi ); }//ïîëó÷àþ îòêóäà áûë çàïóùåí } else { strcpy( PathImage, "???" ); } return PathImage; } ------------------------------------------------------------------------------- Hi, all. I build a file system filter driver based on FILEMON. In IRP_MJ_CREATE dispatch, I want to get the process full path name and the file full path name which is to be opened by the process, the code like this: ///////////////////////////////////////////////////////////////////////////////// /// PIO_STACK_LOCATION currentIrpStack = IoGetCurrentIrpStackLocation(Irp); PIO_STACK_LOCATION nextIrpStack = IoGetNextIrpStackLocation(Irp); hookExt = HookDevice->DeviceExtension; case IRP_MJ_CREATE: fileObject = currentIrpStack->FileObject; fullPathName = ExAllocatePool(NonPagedPool, MAXPATHLEN ); if(fullPathName) { FilemonGetFullPath( fileObject, hookExt, fullPathName ); } ..... CurrentProcessName = GetCurrentProcessFileName( ); if ((CurrentProcessName != NULL)) { // ... RtlInitUnicodeString(&ProcessUnicodeName, CurrentProcessName); //Errors happened here! } ///////////////////////////////////////////////////////////////////////////////// /// PCWSTR GetCurrentProcessFileName() { DWORD dwAddress = (DWORD)PsGetCurrentProcess(); //PEPROCESS if((dwAddress == 0) || (dwAddress == 0xFFFFFFFF)) return NULL; dwAddress += 0x1B0; //PEPROCESS->Peb if((dwAddress = *(DWORD*)dwAddress) == 0) return NULL; dwAddress += 0x10; //Peb->ProcessParameters if((dwAddress = *(DWORD*)dwAddress) == 0) return NULL; dwAddress += 0x3C; //Peb->ProcessParameters.ImageFile dwAddress = *((DWORD*)dwAddress); return (PCWSTR)dwAddress; } ///////////////////////////////////////////////////////////////////////////////// ///////////// All is work fine except some conditions. For example, we want to debugg an application in VC6(or BCB) and set breakpoints at the fist line in winmain. When we press F5 to start debugging, before stop at the breakpoint we set, a fage fault occurs at the "RtlInitUnicodeString(&ProcessUnicodeName, CurrentProcessName)". At this point, we get the fullpathname: fullpathname = "c:\dev\debug\test.exe" // the application we debugg. CurrentProcessName != NULl, such as 0x8e8. : dd 0x8e8 0x8e8 ????????? ????????? ?????? ????? it means NULL! That means at this time EPROCESS->PEB->PROCESSPARAMETERS->IMAGEFILENAME still not be initilized with proper value. And exam the process list of the system using SOFTICE proc command, I see process "test.exe" is at RUNNING state with both USERTIME and KERNELTIME equal to Zero. Also, I can get the IRP_MJ_CREATE dispatch' process id using PsGetCurrentProcessId(). Ccompare this pid with the process list we get from softice proc command, I find IRP_MJ_CREATE dispatch is running with the context in process "test.exe"! It means process "test.exe" want to open "c:\dev\debug\test.exe". The IRQL is equal to PASSIVE_LEVEL. It is strange! Please give me some advices.
  Message 26 of 30  
30 May 09 08:42
Don Burn
xxxxxx@acm.org
Join Date:
Posts To This List: 941
Processname from PEProcess

Bo's post reminded me that as Daniel pointed out I was incorrect, the item I rememver as being a UNICODE_STRING or a PUNICODE_STRING is the path to the process, the process name has alway been inline. So using the code below, is likely to crash, since both the offset can change, and whether is a UNICODE_STRING or a pointer to one depends on the system. -- Don Burn (MVP, Windows DDK) Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr "Bo Brantén" <xxxxx@acc.umu.se> wrote in message news:82970@ntfsd... > On Sat, 30 May 2009, Maxim S. Shatskih wrote: > >> This string is truncated to IIRC 13 chars, and is not a full pathname. > > It is possible to get the full path from the undocumented structures that > is available, below is two messages that has been posted before to this > list that shows how to do it: > > RH> Hello! > <...excess quoted lines suppressed...> __________ Information from ESET NOD32 Antivirus, version of virus signature database 4116 (20090529) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
  Message 27 of 30  
30 May 09 09:16
Razvan Hobeanu
xxxxxx@yahoo.com
Join Date: 19 Jul 2004
Posts To This List: 92
Processname from PEProcess

This brings back memories. :) That message is almost 7 years old now - the original thread is here: http://www.osronline.com/showThread.cfm?link=3D31216. The "solution" (looking into the EPROCESS and/or PEB using undocumented/prone-to-change offsets) mentioned by Bo Branten has been offered by Konstantin Shilov in the above-mentioned thread. I didn't use it in the end because of crashes due to offset changes on various Windows versions. Therefore, I wouldn't advise anyone to use this solution in a commercial/shipping product unless they are willing to update their driver every time a new Windows version/service pack comes around (which could result in a change of at least one of those offsets). In case that driver runs on an "unknown" (with regard to those offsets) version of Windows, it should refuse to load or at least guarantee not to crash the system (by looking into EPROCESS and/or PEB). Razvan --- On Sat, 5/30/09, Bo Brant?n <xxxxx@acc.umu.se> wrote: > It is possible to get the full path from the undocumented > structures that is available, below is two messages that has > been posted before to this list that shows how to do it: > > RH> Hello! > > RH> How can I get the full pathname for the process > which requested current > RH> IRP? I currently receive the process name (as in > FileMon sample), but I <...excess quoted lines suppressed...>
  Message 28 of 30  
30 May 09 16:37
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 23 Feb 2000
Posts To This List: 4098
Processname from PEProcess

> It is possible to get the full path from the undocumented structures that > is available, below is two messages that has been posted before to this > list that shows how to do it: One of the ways is to access the RTL_USER_PROCESS_PARAMETERS in the user space of the target process, the structure is a part of the PEB and contains the full pathname of the EXE. The PEB address can be obtained by NtQueryInformationProcess. This is how psapi!GetModuleFileNameEx works, at least pre-Vista, and, for instance, XP SP2 firewall (ipnathlp service) uses GetModuleFileNameEx to enforce the per-pathname rules. -- Maxim S. Shatskih Windows DDK MVP xxxxx@storagecraft.com http://www.storagecraft.com
  Message 29 of 30  
31 May 09 02:58
ntfsd member 42967
xxxxxx@yahoo.com
Join Date:
Posts To This List: 21
Processname from PEProcess

Thanks for giving me a lot of inputs through these discussions. So, it looks like I should move out of the kernel space & try to get the process name/path in user mode. I had thought of doing it in the kernel mode only to avoid the round trip to user mode. The particular case I was trying to address is this - The driver should sit in the create path of all files with a particular reparse point set on it. The driver in general would force a particular kind of read (say for example a download across network) before completing the IO request. However, for some applications like desktop search applications, i would want to deny a read to avoid downloads. I was thinking of using the process name to identify such processes.
  Message 30 of 30  
31 May 09 07:15
Pavel A
xxxxxx@fastmail.fm
Join Date: 21 Jul 2008
Posts To This List: 76
Processname from PEProcess

xxxxx@yahoo.com wrote: > Thanks for giving me a lot of inputs through these discussions. > > So, it looks like I should move out of the kernel space & try to get the process name/path in user mode. I had thought of doing it in the kernel mode only to avoid the round trip to user mode. > > The particular case I was trying to address is this - > The driver should sit in the create path of all files with a particular reparse point set on it. The driver in general would force a particular kind of read (say for example a download across network) before completing the IO request. However, for some applications like desktop search applications, i would want to deny a read to avoid downloads. I was thinking of using the process name to identify such processes. > Have you seen this reply? Date: Sun, 31 May 2009 00:36:28 +0400 From: Maxim S. Shatskih > One of the ways is to access the RTL_USER_PROCESS_PARAMETERS in the > user space of the target process, the structure is a part of the PEB and > contains the full pathname of the EXE. The PEB address can be obtained > by NtQueryInformationProcess. This works well enough, at least on XP SP2. Regards, -- pa
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntfsd list to be able to post.

All times are GMT -5. The time now is 01:30.


Copyright ©2014, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license