Diskussion:Rundll32.exe

was ist mit Vista?

könnte bitte jemand, der sich damit auskennt, die wichtigsten Änderungen beschreiben, die sich im Zusammenhang mit Vist ergeben haben oder anmerken, dass diesbezüglich alles gleich geblieben ist?

Danke -- 188.155.218.111 11:43, 27. Mai 2009 (CEST)

Keine offensichtlichen bzw. von Microsoft dokumentierten. Ich kann mir aber gut vorstellen, daß einige DLLs in Probleme mit der UAC reinlaufen. --Peter-HHH 08:21, 22. Mär. 2010 (CET)

Habe vorhandene Beispiele auf Windows 7 getestet und die Ergebnisse hier hinzugefügt (muß noch gesichtet werden) Peter-HHH 23:08, 18. Jan. 2011 (CET)

was passiert wenn man die rundll32.exe löscht?

was passiert wenn man die rundll32.exe löscht? 87.161.226.239 11:57, 23. Aug. 2007 (CEST)

* zuerst mal garnix

* auf NT+ stellt sie die automatische systemwiderherstellung her

* ansonsten ist sie weg, und alles was sie tut (siehe artikel) geht nicht mehr

* empfohlen wird es nicht siehe [1]

* mach ein backup das systems (am besten ein Image) und probiers aus.. - was passiert?

gruß -- W!B: 13:36, 23. Aug. 2007 (CEST)

PATH

Die nachstehende Bemerkung ist gerade nicht zur Nachahmung zu empfehlen, erst recht nicht in verletzlichen systemnahen Bereichen. Man sollte sich angewöhnen, sogar von RUNDLL und SHELL32 nicht nur die Endung, sondern auch den vollständigen Pfad anzugeben – auch wenn MS das nicht so macht. Grund: Leidvolle Erfahrungen mit den Studierenden von MIT, Berkeley usw. haben es in der UX-Welt seit über 30 Jahren Standard werden lassen, auch vor Systemkommandos den /bin/-Pfad zu setzen. Es braucht nur ein böser Bube den %PATH% zu manipulieren, ein Verzeichnis mit Schadsoftware voranzustellen – und auf das wird dann zugegriffen. Es geht noch einfacher: So ist C:\WINNT\EXPLORER.EXE der echte. Den kann man nun mit 1000 Administrator-Schreibrechten gegen Manipulation schützen. Weil meist der %PATH% lautet: C:\WINNT\system32;C:\WINNT – muss nur ein böser EXPLORER.EXE auf system32 platziert werden, der auch den guten Explorer aufruft, und ein nicht zu bemerkender Hack ist gelungen. Dagegen hilft auch nicht, die Registry-Einträge für die PATH-Environment durch Administratorrechte gegen Veränderung zu schützen (wie mit regedt32 möglich). -- PerfektesChaos im Edit 2008-06-22T19:35:47

Anmerkung: Der Aufruf der Datei kann auch nur mit ihrem Namen erfolgen, da ihr Stammordner in der %PATH%-Systemvariable eingetragen ist und EXE-Dateien bei der automatischen Dateiendungsergänzung an erster Stelle stehen.

stimmt, recht hasu Du --W!B: 02:47, 23. Jun. 2008 (CEST)

Fehler bezüglich Win98

Die ersten zwei Zeilen: runDLL32.exe ist eine Programm-Datei der Windows-NT-Serie und ein Grundbestandteil des jeweiligen Betriebssystems der Serie. Unter Windows 95/98 hieß die Datei RUNDLL.exe... sind so nicht richtig. Win98 verfühgt bereits über die rundll32.exe und hat aus Kompatiblitätsgründen noch die rundll.exe an Board, beide im Verzeichnis root:\Windows\. --T weimar 13:41, 10. Jan. 2011 (CET)

Wenn du das zweifelsfrei verifizieren kannst, dann ändere halt den Artikel. Ich hatte persönlich nie in den Innereien der 95/98-Serie herumgewirtschaftet, sondern war (wenn überhaupt) auf der NT-Linie. Selbst wenn, könnte ich mich aus dem Gedächtnis nicht mehr erinnern, wie vor zehn Jahren mal ein Programm hieß. Ich habe auch keinerlei Zugriff mehr auf eine Win98-Mühle. Deine Anmerkung klingt aber plausibel, da 95→98 die Umstellung auf 32bit erfolgte und in deren Zusammenhang die *32.* aufkamen. Dass alte Versionen zur Kompatiblität noch mitgeschleppt werden, bedarf keiner Erwähnung im Artikel, mag aber die Ursache eines Irrtums des damaligen WP-Autors gewesen sein. Bei der Gelegenheit kannst du auch gern die sinnfreie Bemerkung zur Groß- und Kleinschreibung entfernen. --PerfektesChaos 10:02, 15. Jan. 2011 (CET)

Ich würde die ersten sechs Zeilen durch folgenden Text ersetzen.

"rundll32.exe ist ein Win32-Dienstprogramm von Windows ab Version Windows 95 und wird verwendet, um Win32-Funktionen aus Programmbibliotheken als eigenständige Routinen auszuführen. Dabei können nur Funktionen ausgeführt werden, die in der Programmbibliothek explizit für das Ausführen mit diesem Dienstprogramm deklariert wurden. In älteren Windowsversionen (Windows 95 bis Windows Me) ist aus Kompatibilitätsgründen die 16-bit-Version rundll.exe zum Ausführen von Win16-Funktionen noch enthalten.

Die Datei befindet sich bei Windows NT bis Windows 7 im Ordner %windir%\system32 (also zum Beispiel C:\WINNT\system32) und bei Windows 95 bis Windows ME im Ordner C:\Windows."

Der Speicherort für WinMe müsste noch mal geprüft werden.

Kann mir jemand bei den Einzelnachweisen helfen. ich würde folgenden gern hinzufügen.

"Einzelnachweis: http://support.microsoft.com/kb/164787"

MfG --T weimar 20:27, 5. Feb. 2011 (CET)

Hört sich gut an; schreib es einfach in den Artikel hinein. ME-Pfad klingt plausibel; es ist insofern nicht von fundamentaler Bedeutung, weil 1. historisch und 2. konfigurierbar. Bring den Einzelnachweis in Klammern an genau der Stelle an, wo du etwas belegen möchtest; ich bekomme das mit und mache anschließend die Formatierung. Dann siehst du, wie es geht, und kannst es beim nächsten Mal selbst. Nur Mut! --PerfektesChaos 22:12, 5. Feb. 2011 (CET)

Erklärung zu meinen letzten Edits

Ich schrieb Das führt in jedem Fall zu einer Korruption des Stacks [7] und zu unvorhergesehenem Verhalten, beispielsweise Endlosschleifen. Der geneigte Kritiker möge jetzt anmerken, dass die Programme, welche die Signatur-Regel missachten, trotzdem weiter laufen, ergo der Stack nicht korrupt sein könne. Das ist nicht der Fall. Wie Raymond ausführt, tritt die Korruption mangels korrektem Aufräum-Code in jedem Fall ein. Vor Windows Vista war das allerdings oftmals kein Problem, weil die alte Implementierung das "einfach ausgehalten" hat. Man möge mir deshalb nachsehen, dass unvorhergesehenem Verhalten auch die erwartete Weiterführung des Programms bedeuten kann. - Invitam 13:06, 12. Sep. 2011 (CEST)

Gesichtet, passt schon. – Wenn du dich schon grad eingearbeitet hast, berichtige doch bitte gleich die „auch von Beispielen auf dieser Seite“. – Es ist völlig klar, dass man Funktionen so zu benutzen hat, wie vom Provider/Programmierer ausdrücklich dokumentiert, und nicht irgendwie anders. Ich hasse Leute, die mir dummschwätzend kommen mit „ach wir haben da einfach null übergeben, es funktioniert ja schließlich trotzdem“. Liebe Grüße --PerfektesChaos 13:28, 12. Sep. 2011 (CEST)

Danke. Ich habe allerdings auf die Schnelle da nichts passendes zu gefunden. Aus praktischen Erwägungen heraus würde ich annehmen, dass die Funktionen mit "rundll" im Namen dafür vorgesehen sind. Dummerweise ist sind die meisten nicht dokumentiert. Ich habe außerdem mal ein wenig in der Shell-Bibliothek gestöbert - und habe dort keine Funktion mit passender Signatur gefunden. Ich werde dem mal beizeiten nachgehen, aber momentan fehlt mir die Muse. - Invitam 14:15, 12. Sep. 2011 (CEST)

(Anm: Ein Beispiel für die Missachtung wäre etwa "powrprof.dll,SetSuspendState" mit Signatur BOOLEAN WINAPI SetSuspendState( __in BOOLEAN Hibernate, __in BOOLEAN ForceCritical, __in BOOLEAN DisableWakeEvent);) - Invitam 14:18, 12. Sep. 2011 (CEST)

Dateieigenschaften

Kann man mittels rundll32 auch den Eigenschaften-Dialog einer beliebigen Datei aufrufen ? -- Juergen 80.132.167.68 03:36, 17. Feb. 2014 (CET)

• Eigentlich sollte es sowas geben, wie du sinnvoll vermutest. Ist jedoch keine Verpflichtung.
• Ich habe die gleiche Fragestellung dutzendfach im Netz gefunden, aber keiner der Experten konnte einen Aufruf per rundll liefern.
• Es gibt auch eine große Zahl voneinander abgeschriebener Auflistungen von rundll-Möglichkeiten, aber dieser Dialog war nicht dabei. Microsoft schweigt sich offiziell aus.
• Daher unterstelle ich mal, dass es den Einstiegspunkt nicht gibt.
• Der Dialog steht mit ziemlicher Sicherheit in der shell32.dll etc. – in der steht der Datei-Explorer.
• Diese hat einige benannte Einstiegspunkte. Über jeden dieser Einstiegspunkte, die wie der Aufruf eines „Hauptprogramms“ wirken würden, können Funktionalitäten aus der DLL gestartet werden, und dabei auch Parameter übergeben werden.
• Der Dialog zu den File properties ist offensichtlich nur ein Unterprogramm; das könnte man zwar ganz fies über einen Hexcode gestartet bekommen, aber der ist bei jeder Windowsversion und ggf. jedem Build anders.
• Meine Folterwerkzeuge für Microsoft habe ich grad nicht einsatzbereit; aber ich kenne jemand, der sowas zur Hand haben dürfte.

LG --PerfektesChaos 23:47, 17. Feb. 2014 (CET)

Sodele, freundicherweise hat mir jemand die DLL-Struktur zugespielt.

• Vorweg: Es ist offenbar kein geeigneter Einstiegspunkt in der shell32.dll vorhanden.
• Es gibt SHGetFileInfo – klingt vielversprechend, liefert aber eine Datenstruktur, keine optische Darstellung.
• Es gibt: SHObjectProperties
  • Das ist eigentlich das, was gebraucht wird:

    Invokes the Properties context menu command on a Shell object.

  • Problem: Das ist ein Unterprogramm, das nur aus einem C++-Programm aufgerufen werden kann.
  • Zwar ist:

    SHOP_FILEPATH = 0x00000002

    SHOP_VOLUMEGUID = 0x00000004

    – aber es funktioniert trotzdem nicht:

    rundll32.exe Shell32,SHObjectProperties 0,2,C:\Temp\test

  • Vielmehr müsste ein „Hauptprogramm“-geeigneter Einstiegspunkt vorhanden sein, wie er umseitig unter microsoft.com verlinkt ist:

    void CALLBACK
EntryPoint(HWND hwnd, HINSTANCE hinst, LPSTR lpszCmdLine, int nCmdShow);

  • Den hat beispielsweise ShellAbout – deshalb geht

    rundll32.exe Shell32,ShellAbout

• Einen solchen Einstiegspunkt kann ich in der shell32.dll nicht finden.
• Es müsste jemand ein 10-Zeilen-Programm (.exe oder .dll) in C/C++ schreiben, das einen übergebenen Kommandozeilen-Parameter mit dem Pfad von Datei/Verzeichnis (sofern vorhanden) an die herbeigelinkte shell32.dll ihrer Funktion SHObjectProperties() übergibt.

Beste Grüße --PerfektesChaos 10:46, 18. Feb. 2014 (CET)

Ah, Danke fuer Deine super Reaktion.

Ich habe zwar schon diverse C-Programme geschrieben, aber noch nicht fuer Windows.

Aber ich habe hier cygwin mit gcc auf Win7 am Laufen und mal eben folgenden Schnellschuss fabriziert:

(Die erledigte Diskussion ueber statisches und dynamisches Linken, die hier nicht hingehoert, wieder geloescht.)

(Die alte Version des Programmes wegen der Uebersicht hier entfernt.) Das Programm ist also aufrufbar, aber es funktioniert nicht. Der einzige Fall, in dem ich eine Success-Meldung erhalte, ist die Uebergabe eines leeren Strings: ObjectProperties "" - in diesem Fall oeffnet sich die Systemsteuerung. Mir ist nicht klar, was man uebergeben muss, um eine Datei zu oeffnen.

Ausserdem ist mir aufgefallen, dass die Funktion irgendwie den uebergebenen String loescht: Jedenfalls funktioniert die Ausgabe des erzeugten Wide-Strings nach dem Aufruf nicht mehr, vorher aber schon (siehe die Ausgabe de Programmes: vor dem Failure kommt noch eine Zeile, danach aber nicht mehr).

Wer hilft mir ? Und soll ich zu Testzwecken das erzeugte Executable irgendwo hochladen ? -- Juergen 80.132.177.58 10:12, 22. Feb. 2014 (CET)

1. -mwin32 hätte mir auch einfallen können.
   • Ich habe allerdings gcc immer nur in der UX-Welt eingesetzt und in der MS-Welt mich immer nur in das gemachte Nest des Studio gesetzt, ohne mich um diese Umgebungsfragen zu kümmern.
2. Die Doku zu SHObjectProperties spricht von einem „fully qualified file name“.
   • Das heißt, er will den Pfad ab C:\ sehen; SHObjectProperties ist nicht gewärtig, in einer Umgebung zu laufen, in der ein curdir definiert wäre.
   • Deshalb funktioniert der leere Pfad; als Systemsteuerung.
   • Dateiname ohne Pfad kann er nicht finden, und tut nix.
3. Windowisierung:
   • Einige eigenwillige Konstrukte, die vom üblichen Stil von Windows-Progammen abweichen und Typfehler usw. bewirken können.
   • Hier heißt das: WinMain
   • Siehe #C mit Windows API
   • WinMain entry point – beachte die grundsätzliche Analogie zum DLL entry point oben.
   • Wenn du mehrere Dateinamen angibst (die in " einzuschließen sind, falls sie Leerzeichen enthalten), hilft CommandLineToArgvW.
4. Warum er dir den path gemopst hat (vielleicht nur eine 0 auf [0] geschrieben?), weiß ich auch nicht.
   • Möglicherweise lässt er das bleiben, wenn er die Datei auch finden konnte.
   • Quellcode begucken reicht, Bimärcode würde ich nicht anfassen wollen.
   • Ich habe grad keine Entwicklungsumgebung einsatzbereit, sonst hätte ich selbst mit den paar Zeilen experimentiert. Aber so ist der Lerneffekt größer.

Schönen Sonntag --PerfektesChaos 10:56, 23. Feb. 2014 (CET)

So, mit Deiner Hilfe habe ich es jetzt geschafft: Dieses Programm oeffnet fuer jedes Argument entweder den gewuenschten Eigenschaften-Dialog oder aber ein PopUp mit einer Fehlermeldung. Am Ende wird eine Close-Message angezeigt: Wenn man diese wegklickt, schliessen sich auch die geoeffneten Eigenschaften-Dialoge wieder. Und das war auch die Ursache fuer die o. g. Nichtfunktion: Der Eigenschaften-Dialog ist (im Unterschied zur Close-Message am Ende) nicht modal, also der Aufruf von SHObjectProperties kehrt schon zurueck, wenn der Dialog geoeffnet wurde, und nicht erst dann, wenn der Benutzer ihn wieder geschlossen hat.

Da ich nicht so recht weiss, wohin ich ein Executable hochladen kann, gibt es hier nur den Quelltext - dieser hier compiliert mit gcc unter cygwin ohne Warnings, laeuft aber bestimmt unveraendert auch unter allen anderen Windows-Compilern. -- Juergen 80.132.162.57 22:02, 23. Feb. 2014 (CET)

// ObjectProperties.c  -  open the Properties Dialog of a file
// This software by Juergen is in the public domain.
#include <shlobj.h>
#include <wchar.h>
int main ()
{
  int argc;
  LPWSTR *argv = CommandLineToArgvW (GetCommandLineW(), &argc);
  HMODULE Shell32 = LoadLibrary ("C:\\Windows\\System32\\shell32.dll");
  FARPROC pSHObjectProperties =
    GetProcAddress (Shell32, "SHObjectProperties");
  while (*++argv) {
    // Duplicate the string - it seems to be freed by SHObjectProperties:
    WCHAR *path2=wcsdup (*argv);
    if (! (BOOL(*)(HWND, DWORD,PCWSTR, PCWSTR)) pSHObjectProperties (
      NULL, SHOP_FILEPATH, path2, NULL
    )) {
      WCHAR buf[1024];
      // GetLastError() does not return anything here:
      swprintf (buf, 1024, L"SHObjectProperties (\"%s\"): failure", *argv);
      MessageBoxW (0, buf, L"ObjectProperties", MB_OK);
    }
  }
  MessageBox (0, "Close dialogs", "ObjectProperties", MB_OK);
  return 0;
}

gcc -mwin32 -o ObjectProperties.exe ObjectProperties.c && ObjectProperties W:\ObjectProperties.c k W:\ObjectProperties.exe

Defekter Weblink

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://www.codeproject.com/KB/system/SystemDialogs.aspx
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/http://www.codeproject.com/KB/system/SystemDialogs.aspx

– GiftBot (Diskussion) 11:04, 4. Jan. 2016 (CET)