CLR20r3 - Suche nach Fehlerquelle

  • VB.NET

Es gibt 10 Antworten in diesem Thema. Der letzte Beitrag () ist von Access99.

    CLR20r3 - Suche nach Fehlerquelle

    Hallo,



    ich habe ein Datagridview mit einigen Spalten. Alles funktioniert sowie.

    Ab und zu habe ich folgende Fehlermeldung. Ich kriege die Meldung aber nicht nachgestellt und nich im Debugger.



    Hat jemand noch eine Idee? Der Fehler tritt sehr selten auf, aber ab und zu halt.



    Problemsignatur:

    Problemereignisname: CLR20r3

    Problemsignatur 01: programm.exe

    Problemsignatur 02: 1.0.0.0

    Problemsignatur 03: 52ff4e39

    Problemsignatur 04: Programm

    Problemsignatur 05: 1.0.0.0

    Problemsignatur 06: 52ff4e39

    Problemsignatur 07: 5be

    Problemsignatur 08: 846

    Problemsignatur 09: System.TypeInitialization

    Betriebsystemversion: 6.1.7601.2.1.0.16.7

    Gebietsschema-ID: 1031

    Zusatzinformation 1: 87b1

    Zusatzinformation 2: 87b137ec4f5c2d56904023e9c27c42e5

    Zusatzinformation 3: 4f58

    Zusatzinformation 4: 4f58d7489aafb4f486692e3965c7c3d4





    Bin für Tipps dankbar.

    diylab schrieb:

    Welches Framework?
    Welches Betriebssystem?
    Welches Studio?
    Any oder 32 Bit oder 64 Bit?

    // Es scheint so, als ob Dein Programm auf einem Windows 2008 R2 x64 Server läuft?

    LG,
    Bruno

    Hallo,
    es ist eine Anwendung für Windows Terminalserver. Das OS ist Windows 2008 Server R2 mit Framework 4.0
    Entwickelt wird unter VS 2012 mittlerweile (unter 2010 war das Problem auch da). CPU ist Any. Das OS ist 64 Bit, aber einige nutzen es lokal und daher habe ich Any eingestellt.

    Das ist ziemlich nervig, weil ich es nicht nachstellen kann und nicht weiß wann es passiert. Die User starten das Programm dann neu und alles funktioniert wieder. Es kommt sehr sporadisch vor.
    was meinst du mit komplett installiert? Ja, es ist die komplette Framework 4.0 Version.

    Und im Visual Studio Projekt nutze ich 4.0 -> nicht Client Profil.
    Das habe ich als erstes untersucht. Kann es sein das irgendein zusätzliches Element auf den Servern fehlt? Was auf dem Entwicklungsserver drauf ist!? Aber nur welches, das ist nicht ganz einfach. Vor allem weil die Anwendung reibungslos funktioniert und dann plötzlich mal crasht.

    Danke dir für die Überlegungen.

    Edit: Sehe jetzt erst deinen Link. Den schaue ich mir jetzt an.
    Vielleicht noch ein paar weitere Überlegungen:

    - für ausgewählte User eine reine 32Bit Version kompilieren und testen lassen
    - Welche DB hängt an der Anwendung? Sollte es statt MS-SQL doch MySQL sein - welcher .NET Connector wird benutzt?
    - Werden Win-APIs benutzt? Dann unbedingt den ersten Punkt testen.
    - Sind Fremdkomponenten im Spiel? Gibts Updates dafür?
    - werden DDLs benutzt, die im Systemverzeichnis sein müssen? 32Bit DLLs immer in c:\Windows\SysWOW64 stopfen.

    LG,
    Bruno
    Noch eine Idee:

    Kannst du JIT-Debugging aktivieren (siehe blogs.msdn.com/b/reiley/archiv…ever.aspx?Redirected=true und msdn.microsoft.com/en-us/libra…f542967%28v=vs.85%29.aspx)? Wenn ja, dann stell die Anwendung mal als "Debug" kompiliert bereit und lass sie verwenden. Warte. Wenn sie dann abstürzt, kannst du dich mit einem JIT-fähigen Debugger (VS oder WinDbg) an den Absturz hängen und bekommst hoffentlich einen Stacktrace.

    Allgemein: System.TypeInitialization[Exception] ist eine sehr allgemeine Exception, die die wirkliche Exception umschließt (laut Doku). An die InnerException kommst du im Debugger dran - siehe oben.

    Falls du den Debugger nicht anhängen kannst, bleibt dir nur Tracing - gib Statusmeldungen aus, bevor und nachdem du irgendwas machst. Bei großen Programmen ist das sehr aufwendig. Du solltest dafür schon eine ungefähre Vermutung bzgl. der Absturzstelle haben.
    Gruß
    hal2000
    Mir ist noch folgende Meldung in der Ausgabe aufgefallen. Es wird nicht als Fehler oder Warnung angezeigt.

    Komme leider nicht dahinter wie ich das beseitige. Die System.web habe ich nicht mehr in den Verweisen. Die habe ich früher meine ich benutzer.



    "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3102,5): warning MSB3178: Die System.Web.dll-Assembly wurde falsch als Datei angegeben."







    Edit: Habe es eben gefunden. Die Dll war noch in den Anwendungsdateien verwaltet. Jetzt ist die Warnung raus. Mal schauen, ob es morgen vielleicht schon besser ausschaut.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Access99“ ()