Problemereignisname CLR20r3

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 14 Antworten in diesem Thema. Der letzte Beitrag () ist von GreenBear.

    Problemereignisname CLR20r3

    Hallo ^^ ,

    ich bekomme die Fehlermeldung "Archivierung_NL funktioniert nicht mehr" mit dem Ereignisnamen "CLR20r3" (siehe Anhang) von meinem Programm auf einem Windows Server 2012R2.

    Das Programm wurde auf einem Windows Server 2019 programmiert.

    Das Problem tritt gelegentlich beim Hinzufügen von einem eigenen Steuerelement, das Informationen aus der Datenbank darstellen soll, auf.

    Das neueste Framework ist auf dem Zielserver installiert und der Kompatibilitätsmodus macht meiner Meinung nach keinen Sinn, da er ja (wenn ich es richtig verstanden habe) für eine
    Abwärtskompatibilität gedacht ist.

    Ich bin wirklich verzweifelt und für jeden neuen Ansatz dankbar.
    Bilder

    • CLR20r3.png

      112,08 kB, 891×583, 287 mal angesehen
    We are all suckerz for something ...

    Schau mal auf dem Server, wo der Fehler auftritt in die Ereignisanzeige. Da bekommst du vom Framework vielleicht eine bessere Fehlerbeschreibung. Habe mal ein bisschen Gegoogelt. In einem Beispiel war z.B. dann zu erkennen, dass es eine ObjectDisposedException gab, die an einer ungünstigen Stelle aufgetreten ist und nicht richtig gefangen worden ist. Benutzt du Multithreading? Hatte schon mal den Fall, das in meiner PC einfach zu schnell war und nur auf einem langsamen dann ein Multithreading Fehler aufgetreten ist. Daher konnte ich den nicht direkt nachstellen. War aber falsch Programmiert.

    GreenBear schrieb:

    Es passiert in der Entwicklungsumgebung nicht und auf dem Zielserver nur gelegentlich
    Hast du auf dem Server die Release oder die Debug Version installiert?
    Passiert das auch mit der Debug-Version?
    Wenn ja, hilft Remote-Debugging.

    GreenBear schrieb:

    Das Problem tritt gelegentlich beim Hinzufügen von einem eigenen Steuerelement, das Informationen aus der Datenbank darstellen soll, auf.
    Kannst du den Code-Extrakt mal hier posten?
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    erstmal danke für die Antworten.

    Auf dem Server liegt die Exe aus dem Debug Verzeichnis. Ich weiß inzwischen in welcher Zeiler er aussteigt.
    "cNeueLadestelle" ist dabei ein Objekt, dass die darzustellenden Daten beinhaltet. "ladestelle" ist ein von mir (mit visual Studio) generiertes Steuerelement, dass diese Daten
    darstellen soll. Ich habe über die Stelle wo er aussteigt einen entsprechenden Kommentar hinterlassen (an der Stelle wo das Steuerelement zum tablelayoutpanel hinzufügt wird). tlpLadestellen.RowCount ist an dieser Stelle übrigens nicht 0 wenn er abstürzt. Also daran liegt es nicht.

    Vielleicht fällt ja jemandem was auf.
    Ich geh auch mal auf die Suche.


    VB.NET-Quellcode

    1. ''' <summary>
    2. ''' Fügt der Oberfläche ein neues Ladestelle Steuerelement zu
    3. ''' in das Informatinen zu einer Ladestelle angegeben werden
    4. ''' </summary>
    5. Private Sub LadestelleHinzufuegen(cNeueLadestelle As clsLadestelle)
    7. If sTempFilePfadAdresse = "" Then
    8. MsgBox("FEHLER: Der Adresspfad ist leer")
    9. Exit Sub
    10. End If
    12. Dim ladestelle As New Ladestelle(cNeueLadestelle, cBenutzer, sTempFilePfadAdresse, Me, cSpeichern)
    13. ladestelle.Dock = DockStyle.Fill
    14. tlpLadestellen.RowCount += 1
    16. tlpLadestellen.RowStyles.Add(New RowStyle(SizeType.Absolute, ladestelle.Height + 25))
    18. ladestelle.Tag = cNeueLadestelle.nummer
    20. 'Bei diesere Zeile stürzt das Programm gelegentlich ab
    21. tlpLadestellen.Controls.Add(ladestelle, 0, tlpLadestellen.RowCount - 1)
    23. ladestelle.lstDateien.SelectedIndex = -1
    25. lstLadestellenControl.Add(ladestelle)
    27. End Sub
    We are all suckerz for something ...

    @RodFromGermany Im ersten Beitrag von diesem Thema siehst du das Fenster, das auf geht. Der Problemereignisname "CLR20r3" bringt mich leider kaum weiter.

    Ich hab mir mit Protokollierung in einer .txt-Datei weiter geholfen um die Stelle auszumachen
    We are all suckerz for something ...

    @GreenBear Probierma:
    Nimm die Debug-Exe und ggf. DLLs und die kommunizierenden pdb-Dateien, da kommt ggf. eine qualifiziertere Fehlermeldung.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Also mein Programm erstellt jetzt nicht mehr dynamisch die Steuerelemente. Sondern ich zeichne beim Start 5 Steuerelemente auf die Oberfläche und fülle und zeige diese je nach Bedarf.

    Seitdem bleiben die Abstürze aus.

    Da möchte man professionell arbeiten und schafft sich damit mehr Probleme. Naja so ist es wohl manchmal.
    Ich hoffe ich konnte jemandem helfen, der ein ähnliches Problem hat.
    We are all suckerz for something ...

    GreenBear schrieb:

    Da möchte man professionell arbeiten
    Ich stelle mir die Frage, was professioneller ist:
    Die Controls statisch vorzuhalten und die Sichtbarkeit an- und abzuschalten
    oder sie jedesmal zu erzeugen und wieder zu löschen.
    Ich behaupte, dass beim dynamischen Verfahren außer der Stabilität auch die Performance kräftig leidet.

    Solange die Anzahl der Steuerelemente einigermaßen abzählbar und vorhersehbar ist, würde ich immer das statische Verfahren bevorzugen.
    Und falls es tatsächlich sehr viele Controls werden, würde ich ggf. das Konzept überdenken.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --