LVM_FINDITEM, Taskmanager stürzt ab

[Neotracer64]

Ich wollte einen bestimmten Prozess in der SysListview32 des Taskmanagers suchen und die Zahl des Items rauskriegen.
Ich wollte das wie folgend lösen, doch der Taskmanager stürzt gnadenlos ab

Delphi-Quellcode:

function GetTaskmgrProcess(process: String):integer;
var
  wnd: HWND;
  ItemCount: Cardinal;
  LVI: TLvfindinfo;
  ret: Integer;
begin
  wnd :=  FindWindow('#32770', 'Windows Task-Manager');
  wnd :=  FindWindowEx(wnd, 0, '#32770', nil);
  wnd :=  FindWindowEx(wnd, 0, 'SysListView32', 'Prozesse');

  if wnd <> 0 then
  begin
  //ItemCount := SendMessage(wnd, LVM_GETITEMCOUNT, 0, 0);
  //ShowMessage(IntToStr(ItemCount));
  LVI.psz := Pchar(process);
  LVI.flags := LVFI_STRING;
  ret := SendMessage(wnd, LVM_FINDITEM, -1, Integer(@lvi));
  //Showmessage(IntToStr(ret));
  result:=ret;


  end;
end;

Habt ihr ne Idee warum ?

[Basilikum]

mit Integer(@lvi) sendest Du die Adresse des lvi-Records, der auf dem Stack in Deinem Prozess liegt, an den Taskmananger...
der Taskmanager ist jedoch ein anderer Prozess, mit eigenem Adressraum -> die Adresse die in der Message enthalten ist, zeigt im Prozess taskmgr.exe irgendwo ins nichts..... -> Access Violation (im taskmgr.exe)

Abhilfe schafft da vermutlich nur, per VirtualAllocEx im fremden Prozess Speicher für die lvi-Struktur zu reservieren, und dann diese Adresse (im Kontext des fremden Prozesses) in die Message zu verpacken.... -> sehr aufwändig...

[Neotracer64]

Zitat:

Abhilfe schafft da vermutlich nur, per VirtualAllocEx

Danke, ich werd mich mal schlau machen. Wenn ich Probleme hab, meld ich mich hier wieder

[Neotracer64]

Sorry, wenn ich wieder nerve.
Ich hab das jetzt so:

Delphi-Quellcode:

function TfrMain.GetTaskmgrProcess(process: String):integer;
var
  wnd: HWND;
  ItemCount: Cardinal;
  LVI: TLvfindinfo;
  ret: Integer;

  dwPId: DWORD;
  hProc: THANDLE;
  pAddr: pointer;


begin
  wnd :=  FindWindow('#32770', 'Windows Task-Manager');
  wnd :=  FindWindowEx(wnd, 0, '#32770', nil);
  wnd :=  FindWindowEx(wnd, 0, 'SysListView32', 'Prozesse');

  if wnd <> 0 then
  begin

  if BOOL(GetWindowThreadProcessId(wnd,dwPID)) then
  hProc := OpenProcess(PROCESS_VM_OPERATION or PROCESS_VM_READ or PROCESS_VM_WRITE, FALSE, dwPId);
  if hProc <> 0 then
    begin
     pAddr:=VirtualAllocEx(hProc, nil, sizeof(lvi), MEM_RESERVE or MEM_COMMIT, PAGE_READWRITE);

    LVI.psz := Pchar(process);
    LVI.flags := LVFI_STRING;
    ret := SendMessage(wnd, LVM_FINDITEM, -1, Integer(@pAddr));
    result:=ret;

    end;

  end;
end;

Und wen wunderts, es geht immernoch nicht ;( . Was habe ich denn vergessen ? Wo steckt mein Denkfehler ?

[teebee]

Zuerst mal das:
ret := SendMessage(wnd, LVM_FINDITEM, -1, Integer( ->@<- pAddr)) // @ weglassen; Lass mal hier das @ weg, du willst ja die Adresse übergeben, die in pAddr gespeichert ist, nicht die Adresse der Variablen pAddr.

Zweitens hast Du zwar im fremden Prozess den Speicher für LV_FINDINFO reserviert, aber noch nicht belegt. Du musst den entsprechenden Speicherbereich aus Deinem Prozess noch in den fremden Prozess hinüberkopieren, denn sonst steht dort vor dem Funktionsaufruf nur Müll. StichwortWriteProcessMemory.

Gruß, teebee

[Basilikum]

was heisst bei Dir "funktioniert nicht" ?
stürzt noch immer der Taskmanager ab ?

spontan habe ich folgenden Verdacht:
die reservierten Pages befinden sich an pAddr im fremden Adressraum...
und Du nimmst aber noch an, es sei in Deinem Adressraum.... schau Dir mal noch WriteProcessMemory an...
weiter erstellst Du mit LVI.psz := Pchar(process); einen weiteren Verweis auf eine Speicherstelle, die wiederum nur in Deinem Prozess gültig ist (reserviere für die Daten von process im fremden Adressraum Speicher)...

bei Google findet sich übrigens dies: http://www.codeproject.com/threads/int64_memsteal.asp (2. Treffer bei der Suche nach VirtualAllocEx)
sieht für Dein Problem sehr interessant aus

[Luckie]

Du musst dir im fremden Adressraum Speicher reservieren, dort mit WriteProcessMemory reinschreiben und ihn dann mit ReadProcessMemory in eine identische Speicherstruktur in deinem Adressraum kopieren, dann kannst du damit arbeiten. Wie das genau geht, kannst du dir bei meinen LuckieDIPS angucken.

[Neotracer64]

Vielen Dank, euch allen
Hätte ich mir denken können, dass das nicht so einfach wird.
Ich guck mir mal das LuckiDIPS an.

[Luckie]

Hier der Grund:
Der Listview gehört zu den neuen 32-Bit Steuerelemten (Commoncontrols). Das vor weg. Früher, unter 16-Bit Windows, waren die Speicherbereiche der Prozesse noch nicht getrennt, das heißt, ich konnte ohne weiteres auf den Speicherbereich eines anderen Prozesses ohne weiteres zugreifen. Mircosoft hat, aus Kompatibilitätsgrunden, dieses Verhalten auch unter 32-Bit Windows für die damals schon vorhandenen und unter 32-Bit Windows immer noch vorhandenen Kontrolls implememntiert. Aufrufe wie WM_GETTEXT für Edit-felder usw. werden dazu in einen gemeinsamen Speicherbereich gemappt. Für die neu hinzugekommen Kontrolls (Listview, Treeview, Satatusbar, ...) sah Microsoft diese Notwendigkeit nicht. Da Listview_Gettext eigentlich nur einen Zeiger auf einen Buffer zurückliefert, schlägt logischerweise dieser Aufruf fehl, wenn es sich um einen Listview in einem fremden Prozess handelt. Listview_GetItemCount funktioniert, da der konkrete Wert zurückgeliefert wird und kein Zeiger auf einen Buffer.

Lösung: Reserviere Speicher im fremden Prozess, fülle ihn mit WriteProcessmemory und kopier ihn mit ReadProcessMemory in eine identische Struktur in den Adressraum deines Prozesses. Wie das genau geht kannst du dir bei meinen LuckieDIPS ( http://programme.luckie-online.de ) ankucken.