Ich möchte in meinem Code jederzeit in der Lage sein in einen fremden Prozess zu schreiben. Der Code ist für einen Spieletrainer. Mein Code zum schreiben schaut atm so aus:

bool Cmem::Write(long addr, unsigned char *data, unsigned int bytes)
{
	if (PID==0)                     // Do we have a process ID?
	{
		if (!Reopenprocess())	// try to reopen the process
			return 0;
		StoreTrainerInfo();	// recalculation of some moduladdresses
		WriteCodecaves();
		ReactivateOptions();
	}
	if (addr>=0x00400000)		// prevent accessviolations
	{
		unsigned long Protection;
		VirtualProtectEx( hproc, (LPVOID)addr, bytes, PAGE_READWRITE, &Protection);
		if( !WriteProcessMemory(hproc, (LPVOID)addr, (LPVOID)data, bytes, 0) )
		{
			if (!Reopenprocess())// write failed, try to reopen the process
			{
				return 0;
			}
			StoreTrainerInfo(); // recalculation of some moduladdresses
			WriteCodecaves();
			ReactivateOptions();
			VirtualProtectEx( hproc, (LPVOID)addr, bytes, PAGE_READWRITE, &Protection);
			if( !WriteProcessMemory(hproc, (LPVOID)addr, (LPVOID)data, bytes, 0) )	// reopen successfull, try write again
			{
				return 0;
			}
		}
		VirtualProtectEx( hproc, (LPVOID)addr, bytes, Protection, 0);
		return 1;
	}
	accessviolation_prevented++; // increase access violation counter by one
	return 0;
}

Das funktioniert soweit ganz gut, aber ich habe mich gefragt ob das nicht einfacher geht. Anstatt "if (PID==0)" würde ich gerne an der Stelle eine generelle Überprüfung einbauen ob meine aktuelle ProzessID/ Prozesshandle gültig ist. Es ist davon auszugehen das sich beides ständig ändert. Diese Überprüfung sollte sicherstellen das ich problemlos WriteProcessMemory() verwenden kann. Ich möchte den kompletten Code nach dem ersten ...
if( !WriteProcessMemory(hproc, (LPVOID)addr, (LPVOID)data, bytes, 0) )
{
// diesen code hier
}
... vermeiden und dort eine Fehlermeldung/MessageBox einbauen. Diese Fehlermeldung sollte dann in der Theorie NUR auftreten, wenn der Zielprozess zwischen dem Aufruf der Prozess-Gültigkeitsprüfung (jetzt noch PID==0) und WriteProcessMemory() beenden wird.

Sollte die Gültigkeitsprüfung negativ ausfallen muss einfach nur Reopenprocess() aufgerufen werden. Diese Funktion öffnet den Prozess dann neu und speichert PID/hproc innerhalb der Klasse.

Ich könnte wetten die Lösung dafür ist extrem einfach. Bisher konnte ich jedoch im MSDN nix dazu finden wie man PID/hproc von fremden Prozessen überprüft.

Gruß gluestick

Ein Prozess Handle ist solange gültig, wie Du es nicht schließt! Punkt!
Das Handle behält auch seine Gültigkeit, wenn der Prozess beendet wird.
Dein Schreiben in den Prozessraum wird dann dennoch fehlschlagen.

Ein PID ist dann gültig wenn Du OpenProcess auf ihn ausführen kannst. Solange Du ein Handle auf den Prozess hast ist auch der PID existent.

http://msdn.microsoft.com/en-us/library/ms684868(VS.85).aspx

The handles are valid until closed, even after the process or thread they represent has been terminated.

Wenn Du ein Handle geschlossen hast ist es nicht mehr verwendbar für Dich, heißt aber nicht, dass der Prozess nicht noch existiert...

Was bitte ist die Gültigkeit eines PID oder Prozess-Handles?

Ok, dann schei*e formuliert: Wie bekomme ich heraus ob sich hinter einem Handle ein aktiver Prozess verbirgt. Ich meinte also die Gültigkeit im Sinne von *auch verwendbar* für Funktionen wie WriteProcessMemory(). Klar ist das "gültige" aber *tote* Handle einen beendeten Prozesses damit auch verwendbar ... nur es macht keinen Sinn es so zu verwenden.

Habe gerade diese Lösung hier gefunden, ist perfekt:

How to identify a stale handle?
http://nibuthomas.wordpress.com/category/windows-api/

Ein Handle kann recycled werden. Es könnte aus dem Process-Handle ein Event oder ein File Handle werden und dann?
Auch dann wäre ein Handle waitable.

Ein Handle kann recycled werden. Es könnte aus dem Process-Handle ein Event oder ein File Handle werden und dann? Auch dann wäre ein Handle waitable.

Also heißt das mit WaitForSingleObject(hproc,0) kann ich nicht 100%ig sicher überprüfen ob sich hinter dem Handle noch ein laufender Prozess verbirgt?
Ein Handle kann doch sicher erst dann neu verwendet ("recycled") werden wenn man es mit CloseHandle(hproc) wieder freigegeben hat, oder etwa nicht?

Jochen schrieb:

Oder Du machst ein "WaitForSingleObject" mit Timeout 0.

Wenn ich es richtig verstehe widersprechen sich eure Antworten. Was ist den jetzt richtig?, kann man das Codesnippet von...
http://nibuthomas.wordpress.com/category/windows-api/
.. mit ruhigem Gewissen verwenden oder nicht? Dort wird es ja wie Jochen sagte mit Timeout 0 aufgerufen. Von recycelten Handles ist jedoch keine Rede - was mich erneut zur Frage bringt ob der Code korrekt ist?

Geht aber einfacher mit GetExitCodeProcess...

"offenes Handle"

Zu den HANDLEs kann ich sagen, das Windows systemintern zu jeder PID (oder sonstigem Objekt, das mit mit H... (z.B. HDC) aus dem Kernel kommt) für jedes Handle einen Zähler hat. Erzeugst Du Dir mit GetCurrentProcess() ein Handle, dann hast Du ein Pseudohandle. Das ist quasi gemappt (copy by value) auf das echte Handle. Der Wert sollte dieser sein: echtesHandle - 1 = pseudoHandle. Der Handle-Zähler des Systems wird NICHT inkrementiert. Das zeigt sich darin, dass CloseHandle(pseudeHandle) nichts macht. Trotzdem kannst Du IN dem Prozess, auf den sich das Pseudohandle bezieht, mit diesem viel Quatsch machen .
Willst Du aus diesem "weichen" Handle aber ein "hartes" Handle machen, brauchst Du DuplicateHandle(pseudoHandle,pseudoHandle,pseudoHandle,&pseudoHandle,...);.
Jetzt ist Dein PseudoHandle "hart". Der Handle-Zähler Deines Prozesses wurde inkrementiert. Machst Du nun ein CloseHandle(pseudoHandle), lebt Dein Prozess weiter, aber der Zähler des Systems für Deinen Prozess wurde dekrementiert.

Kleiner Tipp am Rande: Alles, was SECURITY_ATTRIBUTES verlagt, kommt aus dem Kernel.