Programm startet nicht oder schließt sofort: Wie finde ich Abhängigkeiten, Rechte- und Kompatibilitätsprobleme unter Windows?

Startabbruch nachvollziehen: Ereignisanzeige, Zuverlässigkeitsverlauf, Crash-Dumps und aussagekräftige Fehlermeldungen

Wenn eine Anwendung nicht startet oder sich unmittelbar wieder beendet, entscheidet die Qualität der Diagnose über den Reparaturweg. Der sichtbare Effekt („kurzes Aufblitzen“ oder gar keine Reaktion) entsteht häufig vor der Benutzeroberfläche: beim Laden von Laufzeitbibliotheken, beim Initialisieren von COM/.NET, beim Zugriff auf Profile, Schlüssel oder geschützte Verzeichnisse oder durch eine harte Beendigung via Exception. Windows hinterlässt dafür mehrere Spuren, die zusammen ein belastbares Bild liefern: Ereignisanzeige, Zuverlässigkeitsverlauf, Windows Error Reporting (WER) und – falls vorhanden – Crash-Dumps. Wichtig ist, Zeitstempel zu korrelieren und den konkreten Fehlercode (Exception, Status, Modul) zu sichern, bevor Maßnahmen die Spuren überschreiben.

Ereignisanzeige: relevante Protokolle und typische Event-Quellen

Die Ereignisanzeige liefert die technisch präzisesten Hinweise, sofern gezielt gefiltert wird. Bei Startabbrüchen dominieren Einträge aus „Anwendung“ und „System“ sowie aus den WER-Kanälen. In „Anwendung“ erscheinen häufig Application Error (Event ID 1000) und Windows Error Reporting (Event ID 1001). Ergänzend treten .NET Runtime (z. B. bei nicht abgefangenen Managed-Exceptions) und SideBySide (Manifest-/WinSxS-Probleme) auf. Im Systemprotokoll sind Service Control Manager relevant, wenn ein Programm als Dienst startet oder Abhängigkeiten zu Treibern/Services besitzt.

Für die schnelle Eingrenzung eignet sich eine zeitbasierte Filterung rund um den Startversuch. Entscheidend sind dabei Felder wie „Fehlerhaftes Modul“, „Ausnahmecode“ und „Fehleroffset“. Ein Ausnahmecode wie 0xc0000005 (Zugriffsverletzung) deutet eher auf Crash/Kompatibilität hin, während 0xc0000135 häufig auf fehlende .NET-Komponenten oder eine nicht verfügbare CLR-Version hindeutet (kontextabhängig: je nach App kann auch eine andere fehlende Abhängigkeit dahinterstehen). Ein SideBySide-Fehler nennt häufig die konkret vermisste Assembly oder Version und ist damit unmittelbarer als ein allgemeiner Startabbruch ohne Dialog.

• Event Viewer öffnen: eventvwr.msc
• Relevante Logs: Windows-Protokolle\Anwendung, Windows-Protokolle\System
• WER-Kanäle: Anwendungs- und Dienstprotokolle\Microsoft\Windows\Windows Error Reporting\Operational
• Side-by-Side-Details: Anwendungs- und Dienstprotokolle\Microsoft\Windows\SideBySide\Operational
• Filter nach Zeitpunkt/Level: Aktuelles Protokoll filtern… (Level Kritisch/Fehler, Zeitraum um den Startversuch)

Zuverlässigkeitsverlauf: Abstürze und Installationsänderungen zeitlich korrelieren

Der Zuverlässigkeitsverlauf ergänzt die Rohdaten der Ereignisanzeige um eine chronologische Sicht, in der Anwendungsfehler, Windows-Fehler, Treiberinstallationen und Updates gemeinsam auftauchen. Das ist besonders hilfreich, wenn Startabbrüche „seit gestern“ auftreten und eine Änderung (Patchday, Treiberwechsel, neue Sicherheitssoftware) als Auslöser infrage kommt. Zuverlässigkeitsereignisse verlinken oft direkt auf die technischen Problemberichte, inklusive „Problemereignisname“ (z. B. APPCRASH), „Fehlerhaftes Modul“ und „Ausnahmecode“.

• Zuverlässigkeitsverlauf öffnen: perfmon /rel
• Zeitraum eingrenzen: im Diagramm den Tag auswählen, an dem der Startabbruch reproduzierbar ist
• Problembericht aufrufen: bei „Anwendungsfehler“ Technische Details anzeigen (Module/Exception sichern)
• Änderungen prüfen: Einträge wie Erfolgreich installiert (Updates) oder Treiberinstallation zeitlich gegen den ersten Fehlerlauf stellen

Crash-Dumps über Windows Error Reporting: belastbare Ursachen statt Vermutungen

Wenn Ereignisse nur generisch bleiben (z. B. 0xc0000005 ohne klare Ursache), liefert ein Crash-Dump die höchste Aussagekraft. Windows kann über WER benutzer- oder systemweit lokale Dumps erzeugen. Diese Dumps lassen sich anschließend mit Debuggern auswerten; bereits die Datei-Existenz und der Zeitpunkt bestätigen jedoch, dass wirklich ein Prozessstart stattfand und nicht bereits die Ausführung blockiert wurde. Für reproduzierbare Startabbrüche sollte die Dump-Erzeugung nur so lange aktiv bleiben, wie sie benötigt wird, da sie Speicherplatz beansprucht.

• Dump-Ordner (Standard, wenn konfiguriert): %LOCALAPPDATA%\CrashDumps
• WER-Registry (pro EXE möglich): HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
• WER-Registry (nur für eine App): HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\app.exe
• Typische Werte: DumpFolder (REG_EXPAND_SZ), DumpType (REG_DWORD; 1 Mini, 2 Full), DumpCount (REG_DWORD)

In Unternehmensumgebungen kann die Dump-Erzeugung per Richtlinie eingeschränkt oder durch Endpoint-Schutz beeinflusst sein. Dann bleibt als Indiz oft nur die WER-Ereigniskette: Ein Application Error-Eintrag ohne nachfolgenden Windows Error Reporting-Report kann auf unterbundene Fehlerberichterstattung, fehlende WER-Übermittlung oder eine sehr frühe Terminierung hindeuten (z. B. durch Sicherheitssoftware oder einen Loader-Fehler, der keinen WER-Report erzeugt). Bei Full-Dumps ist außerdem zu beachten, dass sie potenziell sensible Inhalte enthalten; Ablageorte und Zugriff sollten entsprechend kontrolliert werden.

Aussagekräftige Fehlermeldungen erzwingen: Start aus Konsole, Exit-Codes und Loader-Hinweise

Viele Desktop-Anwendungen zeigen bei frühen Fehlern keinen Dialog. Ein Start aus einer Konsole kann dennoch Loader- und Framework-Meldungen sichtbar machen oder zumindest einen Exit-Code liefern. Bei GUI-Programmen bleibt die Ausgabe oft leer; der Exit-Code ist dann der einzige unmittelbare Hinweis. Parallel lohnt ein Blick auf den Pfad und die genaue EXE, da Startabbrüche auch aus einem falschen Arbeitsverzeichnis, aus einem veralteten Stub-Launcher oder durch „App Execution Aliases“ (z. B. Store-Aliase in den Windows-Einstellungen) resultieren können.

• Start aus CMD mit Exit-Code: "C:\Pfad\app.exe" & echo %ERRORLEVEL%
• Start aus PowerShell mit Exit-Code: & "C:\Pfad\app.exe"; $LASTEXITCODE
• Abhängigkeiten sichtbar machen (wenn Prozess kurz läuft): Get-Process -Name app -ErrorAction SilentlyContinue | Select-Object Name,Id,Path
• Installationspfad verifizieren: Get-Command app.exe (prüft, ob ein Alias/Funktion oder ein anderer Suchpfad greift)

Für die weitere Analyse sind drei Angaben aus den Spuren besonders wertvoll und sollten konsistent notiert werden: exakte EXE (Pfad und Version), „Faulting module name“/„Fehlerhaftes Modul“ sowie der Exception-/Statuscode. Damit lässt sich anschließend sauber trennen, ob der Start am Loader (fehlende DLL, Side-by-Side), an Berechtigungen/Profilzugriffen, an Sicherheitsblockaden oder an einem echten Crash im Code scheitert.

Abhängigkeiten und Integrität prüfen: Laufzeitbibliotheken, DLL-Ladeketten, beschädigte Dateien und Reparatur/Neu-Registrierung

Wenn ein Programm sofort wieder endet, liegt die Ursache häufig nicht im eigentlichen Programmcode, sondern in Abhängigkeiten: fehlende oder falsche Laufzeitbibliotheken, nicht auflösbare DLL-Ketten, beschädigte Programmdaten oder eine Registrierung, die nicht mehr zur installierten Version passt. In diesem Abschnitt steht die technische Integritätsprüfung im Vordergrund: Welche Komponenten müssen vorhanden sein, wie lässt sich die Ladekette nachvollziehen und welche Reparaturwege sind belastbar, ohne das System zu „verbiegen“.

Laufzeitbibliotheken und Framework-Abhängigkeiten verifizieren

Viele Windows-Anwendungen setzen Microsoft Visual C++ Redistributables, .NET (Framework oder .NET Runtime) oder UCRT-Komponenten voraus. Ein Startabbruch ohne sichtbare Fehlermeldung entsteht typischerweise, wenn eine benötigte Side-by-Side-Assembly nicht gebunden werden kann oder ein Prozess bereits beim Laden der ersten Abhängigkeiten aussteigt. Entscheidend ist, zwischen „nicht installiert“ und „falsche Architektur/Version“ zu unterscheiden: Ein 32‑Bit-Programm benötigt die x86-Variante, auch auf 64‑Bit-Windows; 64‑Bit-Anwendungen benötigen x64.

Für .NET ist die Trennlinie wichtig: klassische Desktop-Programme können das Windows-.NET-Framework benötigen, während moderne Anwendungen eine separat installierbare .NET Runtime oder ASP.NET Core Runtime voraussetzen. Bei Unsicherheit hilft die Ereignisanzeige (z. B. .NET Runtime-Fehler) und die Prüfung installierter Runtimes. Reine „DLL nachkopieren“-Ansätze sind in der Regel kontraproduktiv, weil sie Side-by-Side-Binding, Sicherheitsupdates und Signaturen umgehen.

DLL-Ladeketten analysieren: Was wirklich geladen wird

Die klassische Fehlerquelle ist eine DLL, die zwar „irgendwo“ vorhanden ist, aber nicht an der Stelle und in der Version geladen wird, die die Anwendung erwartet. Windows löst Abhängigkeiten anhand definierter Suchreihenfolgen auf; zusätzliche Einflussfaktoren sind u. a. der Anwendungsordner, bekannte Systempfade, Side-by-Side-Mechanismen und die Umgebungsvariable PATH. Besonders kritisch sind „DLL-Hijacking“-ähnliche Situationen in Unternehmensumgebungen, in denen alte Bibliotheken in gemeinsamen Ordnern liegen oder durch Drittsoftware in Suchpfade geraten.

Für eine belastbare Diagnose eignen sich Prozess- und Lade-Logs. Auf aktuellen Windows-Versionen liefern Bordmittel und Sysinternals-Tools die nötige Transparenz, ohne das System zu verändern. Wichtig ist, den Startvorgang möglichst früh zu erfassen, weil viele Programme unmittelbar nach dem Prozessstart scheitern.

• Prozessstart und Modul-Ladevorgänge protokollieren: procmon.exe (Sysinternals Process Monitor) mit Filter auf Process Name is ... und Ereignisse Load Image; Auffälligkeiten sind NAME NOT FOUND, unerwartete Pfade (z. B. aus Benutzerprofilen) und wiederholte Zugriffe kurz vor dem Exit.
• Abhängigkeitsbaum einer EXE prüfen: Dependencies.exe (lucasg/Dependencies) oder dumpbin /dependents "Pfad\Programm.exe" (Visual Studio Build Tools). Bei dynamischem Nachladen über LoadLibrary ist zusätzlich ein Laufzeit-Trace nötig.
• Side-by-Side-Detaildiagnose: sxstrace trace -logfile:%TEMP%\sxstrace.etl
sxstrace parse -logfile:%TEMP%\sxstrace.etl -outfile:%TEMP%\sxstrace.txt
• Prüfen, ob fremde DLL-Versionen „gewinnen“: In Procmon den geladenen Pfad der verdächtigen DLL ermitteln und mit dem erwarteten Programmpfad vergleichen; bei Konflikten die Installationsreparatur bevorzugen statt manuellem Kopieren.

Dateiintegrität und Systemkomponenten: Beschädigungen ausschließen

Beschädigte Dateien betreffen nicht nur Windows-Komponenten, sondern ebenso Programmbinärdateien, Plug-ins, Konfigurationsdateien und lokale Caches. Ein typisches Muster: Ein Update wird unterbrochen, Antivirus/EDR isoliert eine DLL oder ein Storage-Problem erzeugt stille Dateifehler. Die Folge sind Signatur- oder Hash-Mismatches, „Bad Image“-Fehler oder Abstürze in frühen Initialisierungsroutinen.

Für Windows-Systemdateien sind SFC und DISM weiterhin die belastbaren Prüfpfade. Für Applikationen ist die Integrität über den Installer (Reparaturmodus) oder den Paketmanager zuverlässiger als manuelles Ersetzen. Bei Store-/AppX-Komponenten gelten andere Regeln: Hier entscheidet die Paketregistrierung, nicht eine einzelne Datei.

• Windows-Systemdateien prüfen und reparieren: sfc /scannow
• Komponentenspeicher reparieren (bei SFC-Funden oder Update-Artefakten): DISM /Online /Cleanup-Image /RestoreHealth
• Dateisystemfehler als Ursache ausschließen: chkdsk C: /scan (Online-Prüfung); bei Funden Wartungsfenster für Offline-Reparatur einplanen.
• Digitale Signaturen verifizieren (Verdacht auf manipulierte/ersetzte Binärdateien): Get-AuthenticodeSignature "Pfad\Datei.dll" | Format-List

Reparatur, Neu-Registrierung und „saubere“ Wiederherstellung von Programmen

Reparatur sollte über den vorgesehenen Wartungsweg erfolgen, damit Abhängigkeiten, COM-Registrierungen, Dienste, geplante Tasks und Side-by-Side-Manifeste konsistent bleiben. MSI-basierte Installationen bieten meist „Ändern/Reparieren“; moderne Apps nutzen AppX/MSIX-Mechanismen. Bei klassischen Desktop-Programmen ist eine Neuinstallation „über sich selbst“ (gleiche Version) häufig die schnellste Methode, beschädigte Dateien zu ersetzen, ohne Konfigurationen vollständig zu verlieren. Bei hartnäckigen Fällen ist eine Deinstallation mit anschließendem Entfernen verbleibender Programmordner und ein erneuter Installationslauf sinnvoll, sofern Lizenz- und Profilaspekte geklärt sind.

Neu-Registrierung ist nur dort zielführend, wo sie zur Plattform gehört. Für Store-Apps kann eine Paketregistrierung defekte Verknüpfungen und AppModel-Zuordnungen korrigieren. Für einzelne DLLs ist regsvr32 ausschließlich für COM-DLLs geeignet, die diese Registrierungsmechanik unterstützen; das pauschale „Registrieren aller DLLs“ ist fachlich falsch und erzeugt neue Fehlerbilder. Bei COM/ActiveX-Problemen ist zudem die korrekte 32‑/64‑Bit-Variante von regsvr32.exe relevant.

• MSI-Reparatur im Hintergrund anstoßen (falls Produktcode bekannt): msiexec /fa {PRODUCT-CODE-GUID} oder msiexec /i "Pfad\Setup.msi" REINSTALL=ALL REINSTALLMODE=vomus
• AppX/MSIX-Paket für aktuellen Benutzer neu registrieren (Store-App-Probleme): Get-AppxPackage -Name "PaketName" | ForEach-Object {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}
• COM-DLL gezielt registrieren (nur wenn vom Hersteller so vorgesehen): %SystemRoot%\System32\regsvr32.exe "Pfad\Komponente.dll" (64‑Bit)
  %SystemRoot%\SysWOW64\regsvr32.exe "Pfad\Komponente.dll" (32‑Bit)
• Fehlerhafte Nebeninstallationen vermeiden: Vor Reparatur/Neuinstallation konkurrierende portable Kopien und doppelte Programmordner (z. B. unter C:\Program Files und C:\Program Files (x86)) bereinigen, damit die DLL-Ladekette nicht auf „zufällig“ gefundene Bibliotheken abbiegt.

Nach jeder Reparaturmaßnahme sollte die Ladekette erneut geprüft werden, um echte Ursachen von Nebeneffekten zu trennen. Ein Programm, das nach einer VC++-Reparatur startet, aber beim Zugriff auf ein Plug-in abstürzt, hat zwei getrennte Fehlerbilder. Saubere, schrittweise Änderungen und reproduzierbare Logs verhindern, dass mehrere Baustellen gleichzeitig geöffnet werden und die Diagnose im Nachhinein unzuverlässig wird.

Ausführungsblockaden und Benutzerkontext: SmartScreen, Berechtigungen/ACLs, UAC, Sicherheitssoftware und fehlerhafte Benutzerprofile

Wenn Programme nicht starten oder sich unmittelbar wieder beenden, liegt die Ursache häufig nicht in fehlenden Laufzeitkomponenten, sondern im Ausführungskontext: Windows kann den Start blockieren, Rechte können Zugriffe auf Dateien oder Registry verhindern, oder Sicherheitssoftware beendet Prozesse beim Erstellen. Zusätzlich führen beschädigte Benutzerprofile oder inkonsistente Profilpfade dazu, dass Anwendungen beim Initialisieren scheitern, obwohl sie „als Administrator“ scheinbar funktionieren.

SmartScreen, Mark-of-the-Web und Richtlinienblockaden

SmartScreen und der Mark-of-the-Web-Mechanismus (MOTW) greifen, wenn ausführbare Dateien aus dem Internet stammen oder als potenziell unsicher markiert sind. Typisch sind Startabbrüche ohne sichtbare Fehlermeldung, ein kurzer Konsolen-Flash oder ein Eintrag in den Sicherheitsmeldungen. Kritisch ist dabei nicht nur .exe, sondern auch Launcher, Skripte und Installer, die weitere Komponenten nachladen und dann blockiert werden.

Für die Einordnung sind zwei Dinge relevant: ob die Datei einen Zone-Identifier trägt und ob Windows-Schutzmechanismen den Start verhindern. Der Zone-Identifier kann bei Downloads auf NTFS als alternativer Datenstrom gespeichert sein; Entpacken mit bestimmten Tools kann den MOTW auf extrahierte Dateien „vererben“. In Unternehmensumgebungen kommen zusätzlich Richtlinien wie AppLocker oder Windows Defender Application Control (WDAC) hinzu, die Prozesse abhängig von Signatur, Pfad oder Publisher sperren.

• MOTW prüfen/entfernen: Get-Item -LiteralPath "C:\Pfad\App.exe" -Stream Zone.Identifier -ErrorAction SilentlyContinue
Unblock-File -LiteralPath "C:\Pfad\App.exe"
• Defender-/SmartScreen- und Blockereignisse prüfen (kontextabhängig je nach Feature): Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" -MaxEvents 50
• AppLocker-Blockaden sichtbar machen (falls aktiv): Get-WinEvent -LogName "Microsoft-Windows-AppLocker/EXE and DLL" -MaxEvents 100

Berechtigungen, ACLs und „geschützte“ Speicherorte

Viele Startabbrüche sind indirekte Rechteprobleme: Die Anwendung startet, kann aber bei der Initialisierung keine Konfiguration schreiben, keine DLL nachladen oder keine Registry-Schlüssel anlegen. Besonders häufig sind Installationen in C:\Program Files oder das Ausführen portabler Apps aus C:\Windows, C:\ProgramData oder aus synchronisierten/umgeleiteten Ordnern mit restriktiven ACLs. Auch UNC-Pfade oder Netzlaufwerke können durch Richtlinien und Signaturanforderungen eingeschränkt sein.

Ein belastbarer Ansatz trennt zwei Fragen: Hat der ausführende Benutzer Leserechte auf Binärdateien und Abhängigkeiten, und hat er Schreibrechte auf die Pfade, die die Anwendung zur Laufzeit benötigt? Letzteres umfasst neben dem Installationsordner oft %LOCALAPPDATA%, %APPDATA%, %TEMP% sowie anwendungsspezifische Unterordner in %PROGRAMDATA%. Fehlerhafte Vererbung von Berechtigungen, „geerbte Verweigern“-Einträge oder Besitzprobleme zeigen sich häufig erst beim Start.

• Effektive Dateirechte schnell prüfen: icacls "C:\Pfad\App.exe"
icacls "C:\Pfad\Anwendungsordner" /T
• Schreibpfade unter dem Benutzerkontext validieren: set USERPROFILE
echo %LOCALAPPDATA%
echo %TEMP%
• Access-Denied als Ursache belegen (ohne Guessing): Get-WinEvent -FilterHashtable @{LogName="Application"; StartTime=(Get-Date).AddHours(-2)} | Select-Object -First 50

UAC, Integritätsstufen und Kontextwechsel beim Start

UAC-Probleme äußern sich oft als „funktioniert nur als Administrator“ oder als sofortiger Prozessabbruch, wenn die Anwendung stillschweigend erhöhte Rechte erwartet. Technisch geht es weniger um „Admin ja/nein“, sondern um Token, Integritätsstufen und die Frage, ob ein Prozess überhaupt in der Lage ist, privilegierte Orte zu verändern. Anwendungen, die in geschützte Schlüssel unter HKLM schreiben oder in C:\Program Files nachträglich Dateien erzeugen wollen, scheitern unter Standardrechten und beenden sich teilweise ohne UI, wenn Fehler nicht abgefangen werden.

Zusätzlich kann ein Kontextwechsel beim Start auftreten: Ein Updater läuft erhöht, startet anschließend die eigentliche Anwendung jedoch im falschen Benutzerkontext (z. B. „Administrator“-Profil statt interaktivem Benutzer). Dadurch fehlen erwartete Profileinträge unter HKCU oder Dateien in %APPDATA%. Sichtbar wird das, wenn Konfigurationspfade plötzlich unter C:\Users\Administrator landen oder wenn die Anwendung im Autostart unter einem anderen Konto ausgeführt wird.

• Erhöhten Start als Diagnose, nicht als Lösung verwenden: Start-Process -FilePath "C:\Pfad\App.exe" -Verb RunAs
• „Als anderer Benutzer“ gezielt testen: runas /user:DOMAIN\Benutzer "C:\Pfad\App.exe"
• Autostart-/Task-Kontext prüfen: schtasks /query /fo LIST /v

Sicherheitssoftware (AV/EDR) und kontrollierter Ordnerzugriff

Moderne Sicherheitssoftware kann Prozesse nicht nur blockieren, sondern auch nach dem Start unmittelbar terminieren, wenn Verhaltensregeln (Exploit-Schutz, Credential-Access, Injektion) anschlagen. Bei Microsoft Defender spielen neben SmartScreen insbesondere „Controlled Folder Access“ und Attack Surface Reduction (ASR) eine Rolle, die Schreibzugriffe in geschützte Ordner oder bestimmte Prozessketten verhindern können. Das wirkt aus Anwendungssicht wie ein Crash, obwohl tatsächlich eine Policy-Intervention stattfindet.

Für eine belastbare Diagnose sind Ereignisprotokolle entscheidend, weil GUI-Hinweise je nach Konfiguration fehlen. In verwalteten Umgebungen liefern zudem EDR-Konsolen die relevanten Detektions- und Blockdetails; lokal lässt sich oft zumindest nachvollziehen, ob Defender blockiert oder in Quarantäne verschiebt. Jede „Ausnahme“-Entscheidung muss dabei an der Quelle ansetzen (Hash/Publisher/Pfad-Regel), statt pauschal ganze Verzeichnisse freizuschalten.

• Defender-Schutzereignisse und Blockursachen auslesen: Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" -MaxEvents 200
• Controlled Folder Access Status prüfen (falls genutzt): Get-MpPreference | Select-Object EnableControlledFolderAccess
• Defender-Detektionen (Überblick) anzeigen: Get-MpThreatDetection

Fehlerhafte Benutzerprofile, kaputte HKCU-Daten und Umleitungen

Wenn eine Anwendung nur in einem bestimmten Benutzerkonto nicht startet, ist das Profil häufig der entscheidende Faktor. Ursachen reichen von inkonsistenten Profilpfaden (Umzüge, OneDrive Known Folder Move, Domänenwechsel) über beschädigte Cache-/Settings-Dateien bis zu fehlerhaften Einträgen in HKCU, die beim Start ausgelesen werden. Auch fehlende Berechtigungen auf dem eigenen Profilordner sind möglich, etwa nach manuellen Kopieraktionen oder fehlerhaften Backup-Restores.

Zur Eingrenzung hilft ein sauberer Vergleich: Start in einem neu angelegten lokalen Testkonto, Start im abgesicherten Modus mit Netzwerk (nur wenn die Anwendung dort grundsätzlich lauffähig ist) und Abgleich der wichtigsten Pfade. Häufig reicht es, anwendungsspezifische Settings unter %APPDATA% oder %LOCALAPPDATA% testweise umzubenennen, um einen defekten Zustand zu umgehen. Bei hartnäckigen Fällen muss das Profil selbst geprüft werden, insbesondere Profilpfad, Status und SID-Zuordnung in der Registry.

• Profilpfade und SIDs prüfen: reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList"
• Existenz und Zugriff auf zentrale Profilordner verifizieren: dir "%USERPROFILE%"
dir "%APPDATA%"
dir "%LOCALAPPDATA%"
• Testkonto anlegen (Isolation des Benutzerkontexts): net user TestStart /add
net localgroup Users TestStart /add