Unique process id

yakir_elkayam · November 20, 2012, 9:57am

Hello gurus,
I know that there is a way to find out the process id of the current context using PsGetCurrentProcessId(). but from what I read the process is not globally unique in the system ( windows can reuse it once the process is terminated ). My question is, is there a way to query windows for a unique process ID ? As for now I am generating one manually ( tracking each generated process and incrementing some global counter. it’s work but it’s just doesn’t make sense that I need to do it my self.

Any help will do,
Thanks.

Peter_Viscarola_OSR · November 20, 2012, 10:01am

Just to be clear: You’re looking for an ID that is unique per instance of execution… not unique per (something else), right?

Peter
OSR

yakir_elkayam · November 20, 2012, 10:12am

if “instance of execution” means from boot to shutdown then yes. I am logging events in the system to Database and I want to be able to query on an event and process during one windows session.
Thanks,
Jack.

Tim_Roberts · November 20, 2012, 12:08pm

xxxxx@yahoo.com wrote:

if “instance of execution” means from boot to shutdown then yes. I am logging events in the system to Database and I want to be able to query on an event and process during one windows session.

Windows does not have a need for such a unique identifier, so it doesn’t
create such a thing. Once a process is dead, it is irrelevant. (Linux
doesn’t either, FWIW.)

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Don_Burn · November 20, 2012, 12:21pm

As far as I know, no OS has done this. I once did some research in this
area because a customer of a fault tolerant system complained we reused
process ID’s. Since we stayed up for years this was not surprising, but
the customer insisted we “fix it to industry standard practices”. It
turned out the customer wasn’t seeing the problem on other system
because they crashed often enough to not wrap the ID’s. I suggested to
my boss if they insisted we could have them sign a contract to allow us
to crash the system once a week so they would get the same effect.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Tim Roberts” wrote in message news:xxxxx@ntdev:

> xxxxx@yahoo.com wrote:
> > if “instance of execution” means from boot to shutdown then yes. I am logging events in the system to Database and I want to be able to query on an event and process during one windows session.
>
> Windows does not have a need for such a unique identifier, so it doesn’t
> create such a thing. Once a process is dead, it is irrelevant. (Linux
> doesn’t either, FWIW.)
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.

Tim_Roberts · November 20, 2012, 12:28pm

Don Burn wrote:

I suggested to
my boss if they insisted we could have them sign a contract to allow us
to crash the system once a week so they would get the same effect.

Interesting how often this kind of thing comes up. I can’t find the
reference now, but there was a story in the technical press some time
ago about a total failure of the FAA’s communication system in one
section of the country. In the end, the failure was blamed on a lack of
“routine maintenance” (i.e., rebooting) on a server that eventually led
to it staying up for more than 47 days. Now, I don’t know for certain
what operating system they were running, but I know that GetTickCount on
Windows rolls over after 47 days.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Alex_Grig · November 20, 2012, 2:55pm

>Now, I don’t know for certain what operating system they were running, but I know that GetTickCount on Windows rolls over after 47 days.

Win9x had problems with the tick count wraparound.

anton_bassov · November 20, 2012, 4:06pm

> Windows does not have a need for such a unique identifier, so it doesn’t create such a thing.

Once a process is dead, it is irrelevant. (Linux doesn’t either, FWIW.)

Well, although I don’t see any need for any OS to have such a unique ID, I immediately see the reason for doing exactly the opposite, i.e. reusing the ID. After the main thread of a process has entered terminated state and all outstanding references went down to zero, there is no need for any structures that it occupies. Therefore, ythe OS is left with two options - either to free the memory occupied by these structures so that it gets re-purposed, or simply to re-initialize few fields of these structures and immediately reuse them the next time new process is created. Which of them is more reasonable???

The most obvious question is “what does it have with PID and why cannot you assign a new PID for a structure that you want to reuse”. The answer is obvious as well - instead of dumbly assigning an ID to a process you can use it in more meaningful way, i.e. as an index. If you do it this way, you will be able,
given a PID, to locate its corresponding process structure right on the spot, instead of checking the entire process table…

Anton Bassov

Maxim_S_Shatskih · November 20, 2012, 8:14pm

Create a EPROCESS->GUID map (using Rtl AVL tree or your own container, probably STL ported to kmode to not use exceptions), invent a new GUID in a process creation callback and add to the map.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Hello gurus,
> I know that there is a way to find out the process id of the current context using PsGetCurrentProcessId(). but from what I read the process is not globally unique in the system ( windows can reuse it once the process is terminated ). My question is, is there a way to query windows for a unique process ID ? As for now I am generating one manually ( tracking each generated process and incrementing some global counter. it’s work but it’s just doesn’t make sense that I need to do it my self.
>
> Any help will do,
> Thanks.
>

Petr_Kurtin · November 20, 2012, 8:47pm

Use pid + PsGetProcessCreateTimeQuadPart timestamp

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Tuesday, November 20, 2012 3:57 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Unique process id

Hello gurus,
I know that there is a way to find out the process id of the current context
using PsGetCurrentProcessId(). but from what I read the process is not
globally unique in the system ( windows can reuse it once the process is
terminated ). My question is, is there a way to query windows for a unique
process ID ? As for now I am generating one manually ( tracking each
generated process and incrementing some global counter. it’s work but it’s
just doesn’t make sense that I need to do it my self.

Any help will do,
Thanks.

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

OSR_Community_User · November 21, 2012, 10:49pm

>> Windows does not have a need for such a unique identifier, so it doesn’t

> create such a thing.
> Once a process is dead, it is irrelevant. (Linux doesn’t either, FWIW.)

Well, although I don’t see any need for any OS to have such a unique ID,
I immediately see the reason for doing exactly the opposite, i.e. reusing
the ID. After the main thread of a process has entered terminated state
and all outstanding references went down to zero, there is no need for any
structures that it occupies. Therefore, ythe OS is left with two options -
either to free the memory occupied by these structures so that it gets
re-purposed, or simply to re-initialize few fields of these structures and
immediately reuse them the next time new process is created. Which of them
is more reasonable???

Note that Windows has no concept of a “main thread”; in general, the main
thread can exit any time, and the process is live as long as there is any
potentially runnable thread in the process. System Services critically
depend on this behavior. Windows CE and its various evolutionary
renamings got this wrong, and when the “main thread” terminates, the
process terminates.

The process object remains “live” as long as there are outstanding handles
to it, and the process ID will not be reused until the process object is
closed. This is why it is important for a process that calls
CreateProcess to close both the process handle and thread handle when it
no longer needs them. While the address space evaporates in a puff of
greasy blue smoke, the process object remains live in the kernel until its
handle count goes to zero.

After the process object is deleted, the details of whether or not the
fields of a structure are reused or new storage is allocated falls into
the category of Undocumented Magic.

The most obvious question is “what does it have with PID and why cannot
you assign a new PID for a structure that you want to reuse”. The answer
is obvious as well - instead of dumbly assigning an ID to a process you
can use it in more meaningful way, i.e. as an index. If you do it this
way, you will be able,
given a PID, to locate its corresponding process structure right on the
spot, instead of checking the entire process table…

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

anton_bassov · November 22, 2012, 1:42am

> Note that Windows has no concept of a “main thread”; in general, the main thread can exit any time,

and the process is live as long as there is any potentially runnable thread in the process.

???

If you think about it a little bit you will realize that exiting a process would be next to impossible if
everything worked the way you describe. In order to be able to exit, it would first have to terminate all worker threads that it has created,which means it would have to track their state. However, in practice, IIRC, all it has to do is to exit its main loop…

Anton Bassov

Daniel_Terhell · November 22, 2012, 2:21am

>> Note that Windows has no concept of a “main thread”; in general, the main

> thread can exit any time,

Windows does have a concept of primary thread for a process.

> and the process is live as long as there is any potentially runnable
> thread in the process.

That is true. If the primary thread terminates, it doesn’t mean the process
or outstanding threads die. The process continues to live until all
outstanding threads have terminated.

Very often when closing an application it simply takes WAY too much time to
wait for all outstanding threads (which may be involved in a lengthy
function call) to finish gracefully and terminating the outstanding threads
may cause deadlock problems because they may be holding critical sections.

Therefore in my multithreaded software I see no other solution than to kill
those threads and the process with TerminateProcess (not ExitProcess) after
I did the necessary cleanup. AFAIK that’s the only way to do it.

//Daniel

anton_bassov · November 22, 2012, 2:39am

> Windows does have a concept of primary thread for a process.

Well, I don’t know if “main thread” is Win32 concept, but it certainly does exist in Win32 userland…

That is true. If the primary thread terminates, it doesn’t mean the process or outstanding threads die.
The process continues to live until all outstanding threads have terminated.

IIRC, Win32 calls ExitProcess() after the main thread’s main() function (no pun intended) returns control…
I guess the only situation where Joe’s statement applies is the one when someone is perverse enough
to call ExitThread() in app’s main thread…

Therefore in my multithreaded software I see no other solution than to kill those threads and the process with >TerminateProcess (not ExitProcess) after I did the necessary cleanup. AFAIK that’s the only way to do it.

Well, according to MSDN, ExitProcess() is sufficient …

Check http://msdn.microsoft.com/en-us/library/windows/desktop/ms682658(v=vs.85).aspx

Anton Bassov

Daniel_Terhell · November 22, 2012, 2:48am

Excellent trick, I wish I had thought about that before.

//Daniel

“Petr Kurtin” wrote in message news:xxxxx@ntdev…
> Use pid + PsGetProcessCreateTimeQuadPart timestamp
>
>

Ken_Johnson · November 22, 2012, 3:21am

ExitProcess terminates the other threads internally.

In a Win32 program, returning from main eventually leads you to ExitProcess.

S (Msft)

From: xxxxx@resplendence.com mailto:xxxxx
Sent: ?11/?21/?2012 23:21
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re:[ntdev] Unique process id

>> Note that Windows has no concept of a “main thread”; in general, the main
>> thread can exit any time,

Windows does have a concept of primary thread for a process.

>> and the process is live as long as there is any potentially runnable
>> thread in the process.

That is true. If the primary thread terminates, it doesn’t mean the process
or outstanding threads die. The process continues to live until all
outstanding threads have terminated.

Very often when closing an application it simply takes WAY too much time to
wait for all outstanding threads (which may be involved in a lengthy
function call) to finish gracefully and terminating the outstanding threads
may cause deadlock problems because they may be holding critical sections.

Therefore in my multithreaded software I see no other solution than to kill
those threads and the process with TerminateProcess (not ExitProcess) after
I did the necessary cleanup. AFAIK that’s the only way to do it.

//Daniel

—
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</mailto:xxxxx></mailto:xxxxx>

Maxim_S_Shatskih · November 22, 2012, 7:11am

>> Note that Windows has no concept of a “main thread”; in general, the main thread can exit any time,

> and the process is live as long as there is any potentially runnable thread in the process.

???

The thread executing main() or WinMain() calls ExitProcess after return.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Maxim_S_Shatskih · November 22, 2012, 7:12am

> Windows does have a concept of primary thread for a process.

Yes, and this concept is only because on return from main(), the thread will call ExitProcess.

This is CRT’s concept and not kernel’s.

Therefore in my multithreaded software I see no other solution than to kill
those threads

Too dirty. It is really, really possible to do the graceful shutdown of all threads.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Daniel_Terhell · November 22, 2012, 7:19am

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>> Therefore in my multithreaded software I see no other solution than to
>> kill
>> those threads

>Too dirty. It is really, really possible to do the graceful shutdown of all
>threads.

Really not. How can I know whether that thread is in a lengthy OS call (that
may take several minutes) or holding a lock ? I cannot. Because even if I
would be able to save state in a lock free manner to make it visible to the
thread which gracefully requests the termination, that information can be
invalidated at any time (race).

//Daniel

Maxim_S_Shatskih · November 22, 2012, 7:23am

> Really not. How can I know whether that thread is in a lengthy OS call (that

may take several minutes) or holding a lock ? I cannot.

Then wait for this. The file calls can be interrupted by closing a file handle, this cancels the IRPs.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com