Windows-Form öffnet nicht mehr, keine Veraenderungen am Code oder Windows, keine Fehlermeldung

Hi,

ich habe ein selbstgeschriebenes Program in C#, das ich auch häufig nutzte. Das Programm besteht aus einer Tray-Anwendung aus der ich mehrere verschiedene GUIs unabhängig öffnen kann.

Eine dieser GUIs besteht aus einem Windows-Forms-Element mit einem Menu und einem Tab-Control. Da die einzelnen Tab-Elemente eine abgeschlossene Logik haben, nutzte ich für den Inhalt jeweils eine abgeleitete Windows-Forms-User-Control. Diese Forms liegen in einem VS Unterprojekt und liegen dem Programm als dll bei. Ausserdem hat die Gui noch eine Datenbank-Anbindung.

Die einzelnen Tabs kommunizieren, falls nötig direkt untereinander, sowie auch mit der Datenbank.

Das Programm und insbersondere dieses Element, nutze ich seit dem letzten Build (Februar)regelmässig. Allerdings lässt sich seit ein paar Tagen dieses eine Fenster nicht mehr starten. Das Fenster erscheint in der Windows-Taskleiste, bleibt aber nur noch minimiert. Es handelt sich also um ein Problem, das bei einem bereits genutzten Programm neu aufgetaucht ist.

Ich habe keine Veränderungen am Code oder der Datenbank vorgenommen. Mein letztes Windows-Update war vor der letzten korrekten Ausführung. Alle anderen Teile des Programms funktionieren (d.h. unter anderem die Datenbankanbindung funktioniert)
Das Programm kann ich aus VisualStudio 2013 einwandfrei starten, sowohl im Debug- als auch im Release-Modus. Es erscheinen auch keine Fehlermeldungen in der Konsole.
Sonstige Aenderungen am System betreffen eigetnlich nur Update vom Virenscanner oder neu installierte Spiele.

Zur Sicherheit habe ich alle Teile neu kompiliert und die neuste Version in meinen Ausführungsordner kopiert.

Trotzdem lässt sich die Gui nicht öffnen, sondern bleibt minimiert in der Taskleiste.

Meine Frage: wo kann ich anfangen mit der Fehlersuche, und wie kann ich diesen Fehler zumindest in VisualStudio reproduzieren, oder ein Logging erstellen um die Ursache zu finden.

Entwicklungs- und Ausführungsumgebung:
Windows 8.1
Visual-Studio 2013
SQL-Server 2016
.Net Framework 4.5

Konstruktor:

public SyncMain() {
            InitializeComponent(); // autom. generierter Code

            //set the communication channels
            this.syncronize1.setOwner(this);  //tab0
            this.editBook1.setOwner (this); //tab1
            this.editAnthology1.setOwner(this); //tab2

            this.syncronize1.setEditAnthology (editAnthology1);
            this.syncronize1.setEditBook (editBook1);

            this.editBook1.addController(syncronize1);
            this.editAnthology1.addController(syncronize1);
        }

Um es noch einmal zu sagen: dieser Code funktionierte mehrere Monate einwandfrei, ehe das jetztige Problem auftauchte.

edit: ich habe jetzt mal Bilder von der Situation hochgeladen:
VisualStudio.png zeigt den Start aus dem Visual-Studio-Debugger (gewünschtes Ergebnis)
Windows.png zeigt den normalen Start aus der Windows-Umgebung

Vielen Dank für jede Idee

Da es sich ja - so habe ich es verstanden - um ein von dir geschriebenes Program handelt würde ich das Program im EInzelschrittmodus durchgehen (ggf. bei wichtigen Events Brfeakpoints setzen) und schauen was passirt...

Startest du Visual Studio als Administrator? Ggf. mal mit reduzierten Berechtigungen starten und den Debug nochmal ausführen. Möglicherweise kommst du dadurch an eine Exception die irgendwo geworfen wird heran.

EDIT: @Stefan.Haegele ich glaube es wurde gesagt das es sich im Debug Modus nicht reproduzieren lässt.

EDIT2: Weitere Möglichkeit:

Setz in deinem Programm möglichst früh mal ein Codesnippet ein um einen Debugger an das Programm anzuhängen.

https://stackoverflow.com/questions/7276936/start-debugger-in-code

Damit kannst du dann evtl. besser debuggen?!

Werden in dem Program 3rd Party Tools/Anwendungen verwendet? Evtl wurde hier eine verändert - aber wie gesagt - mit dem Debugger sollte das Auffinden des Problems keine Schwierigkeit sein.

@Stefan.Haegele das Tool nutzt eine 3Party-Bibliothek (eine Zip-Bibliothek), allerdings wird in dieser GUI nicht direkt darauf zugegriffen und die Bibliothek liegt noch in der Version vor wie ich sie zum Entwickeln verwendete.

@Kroax Visual Studio startet mit meinen normalen User-Rechten. Danke für den Tipp mit dem Debugger anhängen, ich werd das mal versuchen.

In einer normalen Ausführung scheint das Programm an einer Stelle zu hängen wo eigentlich nur die GUI initialisiert wird. Hier besteht der Grossteil eigentlich aus automatisch generiertem Code, und 2 Boxen die mit Datenbank-Elementen gefüllt werden.

Seltsam finde ich auch, dass das Programm mehrere Monate lief, und dann plötzlich nicht mehr.

Seltsam finde ich auch, dass das Programm mehrere Monate lief, und dann plötzlich nicht mehr.

.. dann wird irgendwas passiert sein, das Du nicht auf dem Schirm hast.
Es ist unwahrscheinlich, dass gar nichts passiert ist und die Anwendung einfach keine Lust mehr hat zu starten.

Trotzdem lässt sich die Gui nicht öffnen, sondern bleibt minimiert in der Taskleiste.

Woran erkennst du das, bzw. wie genau "hängt" das Program? Kann es evtl. sein, daß das Fenster einfach auf einem anderen (evtl. ausgeschalteten) Bildschirm liegt? Oder außerhalb des aktuellen Bildschirmbereiches? Das würde das Verhalten jedenfalls erklären.

Das ist mir schon klar. Mein erster Gedanke war auch deshalb, dass ein .Net Update da etwas zerschossen hätte. Aber so ein Problem hätte das Neukompilieren lösen müssen.

Das ist mir schon klar.

Du machst dir das Leben gerne schwer, stimmts? Führe das Programm doch einfach im Debugger (Visual Studio) aus und du weisst an welcher Stelle das Problem entsteht. Und wie Abt schon sagte - es wird einen Grund geben, weshalb das Program augenscheinlich nicht mehr korrekt startet.

[Artikel] Debugger: Wie verwende ich den von Visual Studio?

Im Debugger steckt die Wahrheit - alles andere wäre raten...

Aber so ein Problem hätte das Neukompilieren lösen müssen.

Hätte es das wirklich?

Danke für den hier wenig hilfreichen Tipp mit dem Debugger...

Wie bereits mehrmals erwähnt: im Debugger funktioniert alles korrekt. Wenn ich den Fehler nicht im Debugger reproduzieren kann, nutzt mir der Debugger grad nichts. Nur reproduzierte Fehler kann ich analysieren.

Ich habe Screenshots hochgeladen wie mein Fenster aus dem Visual-Studio Debugger gestartet aussieht, sowie auch was mein Ergebnis ist wenn ich die identische exe aus Windows heraus starte...

Im Windows habe ich nur das minimierte Fenster, was verkleinert mit dem Maus-Hoover angezeigt wird.

Alles was beim Oeffnen des Fensters nicht aus automatisch generiertem Code (also meine selbst-geschriebenen Teile) stammt, wirft explizit eine Exception... Und ist nicht so relevant, dass das Fenster nicht geöffnet werden kann...

Habe nur den Laptop zum entwicklen und keinen zweiten Schirm, war auch nie ein zweiter Schirm.

Habe Schreenshots hochgeladen wie das Tool sich öffnet. Das Fenster bleibt minimiert hängen, wenn ich in den entsprechenden Taskleisten-Eintrag klicke öffnet sich das vorher zuletzt geöffnete Fenster, nicht das gewünschte...

edit: das Fenster soll sich an der zuletzt geöffneten Stelle im Schirm öffnen, gespeichert über Settings. Ich habe diese grade noch mal überprüft die zeigten nicht ausserhalb des Fensters, und stehen jetzt explizit auf den Koordinaten (1,1)...
trotzdem gleicher Zustand wie vorher....

edit 2 : Läuft jetzt wieder...
Lösung : habe dem neusten Rebuild der Hauptapplikation explizit noch mal eine neue Assembly-Nummer verpasst.
weiss der Kuckuck was Windows da fehlerhaft geladen hat...

Wie bereits mehrmals erwähnt: im Debugger funktioniert alles korrekt. Wenn ich den Fehler nicht im Debugger reproduzieren kann, nutzt mir der Debugger grad nichts. Nur reproduzierte Fehler kann ich analysieren.

Dann können die Dateien nicht identisch sein - oder du hast irgendwo einen Timer der im Debugger u.U. bereits ausgeführt ist...

Lösung : habe dem neusten Rebuild der Hauptapplikation explizit noch mal eine neue Assembly-Nummer verpasst.
weiss der Kuckuck was Windows da fehlerhaft geladen hat...

Du meinst eine neue Version, oder?

[assembly: AssemblyVersion("x.x.x.x")]

Ich glaube eher, dass dein Projekt eine kleine Macke hatte und sich nicht mehr sauber erstellt hat - hier hilft es oft die obj und bin Ordner zu leeren und/oder eine Projektbereinigung durchzuführen!

dein Projekt eine kleine Macke hatte und sich nicht mehr sauber erstellt hat

Jeder Build war zuerst ein clean-Projekt gefolgt von einem vollstaendigen Build. Zusätzlich hatte ich zwischend dem Clean und dem rebuild noch überprüft ob wirklich alle alten Dateien (exes und dlls) entfernt wurden.

Idem für meinen Windows-Ausführungsordner, der an andere Stelle liegt. alte Dateien manuell gelöscht und beim Rebuild neu kopiert.

Die Macke kann nicht aus meinem Projekt selbst kommen: ich hatte das Projekt zwischen letztem erfolgreichen Build und jetztigem Fehler nicht mehr angefasst, aber den Release (ausserhalb von VS) mindestens einmal pro Woche verwendet.

Mein Ausführungsordner liegt vollstaendig ausserhalb von Visual-Studio release und wird beim Debuggen und programmieren nicht angefasst.
Erst nach erfoglreichem Debugging überschreibe ich die Dateien im Ausführungsordner auf die neuste Version. Das garantiert, dass ich immer eine lauffähige Version habe, weil ich mein Programm brauche. Es kommt regelmässig vor dass die Dateien im Visual-Studio nicht identsch zu den "normal" ausgeführten sind, so lange ich am Weiterentwickeln bin. Allerdings hatte ich diesmal explizit die aktuellste Version noch mal kompiliert und in den Ausführungs-Ordner kopiert, was keine Aenderung brachte. Damit wurden aber utner der Windows als auch in der VisualStudio Umgebung die gleichen Dateien ausgeführt.

Vor dem Post hatte ich neukompilieren (clean Build), ausführen in der Debugging-Umgebung, Suche nach ähnlichen Fehlern, bereits versucht. Weshalb sich meine Frage auch darauf bezog ** wie kann ich den Fehler der in der Windows-Umgebung auftaucht in der Visual-Studio-Debugging-umgebung reproduzieren, wo er nicht auftaucht.**

Nur Breakpoints setzen und Code noch mal einzeln durchgehn: sry keine Lösung nach dem Motto: "Mehrmals identisch ausgeführter Code, bringt keine neuen Informationen" . Das hatte ich schon alles gemacht ehe der Code es in meine Release-Version schaffte. So am Rande: wir sprechen hier von einem Gesamtprojekt das seit vielen Jahren gewachsen ist, und mittlerweile locker aus mehreren tausend Zeilen Code besteht.

Assembly-Nummer: Ja ich meine eine neue Versions-Nummer, ich die Assembly-Version von 2.0.* auf 2.1.* hochgestuft. macht an dieser Stelle semantisch absolut keinen Sinn, scheint aber Windows dazu gezwungen zu haben die dll neu zu laden.

Du kannst (bzw. hättest) dich auch an den laufenden Prozess per VS-Debugger hängen können (Menü: "Debug/Attach to Process...").
Probiere das mal aus, damit du beim nächsten Mal weißt, wie das funktioniert.

gespeichert über Settings

weiss der Kuckuck was Windows da fehlerhaft geladen hat...

Evtl. liegt es an den Settings?
Nicht weil Windows die Config-Dateien für die falsche Version liest, sondern weil dort Werte drin stehen, die dein Programm durcheinander bringen können.

Genau das hatten wir auch mal.
Die Usersettings Datei war kaputt und wenn du die Versionsnummer hochzählst wird ja ein neues Verzeichnis erstellt und neue Settings benutzt.

Wir hatten nur immer auch ein Settings Upgrade gemacht.

Die Settings werden unter "%LOCALAPPDATA%<Program>" ("C:\Users<User>\AppData\Local<Program>") abgespeichert.