2

I am using WINAPI for a program that I am writing. The program has the ProcessId of another process and needs to get a handle of it (to be able to terminate it later, and also to periodically check if the process is alive and responding by using WaitForSingleObject). When I compile my program (in Embarcadero RAD Studio 2010 C++ Builder), it works well; the program seems to get the handle successfully and generally works as intended. However, if I launch it from the folder as a standalone exe, it seems to fail to get the handle properly. I checked it by comparing (Companion is a HANDLE and Companion_PID is a DWORD):

GetProcessId(Companion)

and

Companion_PID

Where, a few lines earlier, Companion is taken from Companion_PID in the following code:

Companion = OpenProcess(PROCESS_ALL_ACCESS, FALSE, Companion_PID);

And the "GetProcessId(Companion)" results in 0 (which is a good sign that the OpenProcess failed to return a proper handle.

I'm pretty surprised that this code works differently when run from the compiler and as a standalone exe; I'm assuming in the first case the security attributes are inherited from the compiler itself, but I'd like to hear a possibly better explanation for this behaviour from someone more experienced in WINAPI and security attributes in particular.

Small update: yes, like I thought, OpenProcess results in error 0x5 = ERROR_ACCESS_DENIED.

manlio
  • 18,345
  • 14
  • 76
  • 126
Fy Zn
  • 151
  • 7

1 Answers1

3

From OpenProcess function page in MSDN:

To open a handle to another local process and obtain full access rights, you must enable the SeDebugPrivilege privilege.

I believe your IDE (you're running your application from IDE, not from compiler) has SeDebugPrivilege enabled by default. When you run your application, your IDE (process) is creating a new process which inherits privileges from IDE, including SeDebugPrivilege and that's the reason why function succeeds when run from IDE.

Your application should check whether it has SeDebugPrivilege enabled, and if not, enable it.

Bojan Komazec
  • 9,216
  • 2
  • 41
  • 51
  • Also, IDE is probably running as admin. Non-admin processes generally don't have SeDebugPrivilege in their token at all. – Luke Feb 09 '12 at 16:05
  • I agree, found that VS2010 has this privilege enabled when run as Admin: http://connect.microsoft.com/VisualStudio/feedback/details/682623/sedebugprivilege-enabled-during-ide-debug-session – Bojan Komazec Feb 09 '12 at 16:10
  • Thank you, it seems to be exactly the case. Will dig into this. And yes, I meant IDE; English isn't my native language and I mess the definitions a bit sometimes. – Fy Zn Feb 09 '12 at 16:14
  • A question though; if the process I'm trying to get the handle of is also mine (I can re-write it with modifications), and I need only to Terminate it and Synchronize with it (WaitForSingleObject), do I still need to enable the SeDebugPrivilege, or I can set the security attributes of that process so that it will let my second program get its handle? – Fy Zn Feb 09 '12 at 16:33
  • `OpenProcess()` requires `SeDebugPrivilege`. You must set it and it's easy. Have a look here how to do it: http://msdn.microsoft.com/en-us/library/aa446619(VS.85).aspx – Bojan Komazec Feb 09 '12 at 16:52
  • Ok, will do. The reason of my question was just because I thought of the following variant (if p1 is my process and p2 is the process that I was trying to open in it): p2 executes GetCurrentProcess (pseudo-handle), DuplicateHandle ("converts" to real handle with PROCESS_ALL_ACCESS rights), and sends this duplicated handle to my p1 process which later uses it when necessary. – Fy Zn Feb 09 '12 at 17:09
  • That sounds complicate. Just use `OpenProcess()`. You can disable `SeDebugPrivilege` privilege once you've got the other process' handle. – Bojan Komazec Feb 09 '12 at 17:12