none
WS2012 R2 Terminal Server - Software via Netzlaufwerk (Programm Abstürze) RRS feed

 > 

  • Allgemeine Diskussion

  • Discussion
    Anmelden
    0
    Anmelden

    Hallo zusammen

    Seit immer mehr unserer Kunden auf Windows Server 2012 R2 Terminalserver wechseln, häufen sich Probleme welche unsere Software abstürzen lassen.

    Ich dachte ich teile das nun hier mal - vielleicht hat jemand eine Idee oder ein ähnliches Phänomen...

    Aus teils historischen Gründen wird unsere Software ab einem Netzlaufwerk gestartet.

    Wenn unsere Software (Aussage gem. Entwicklungsabteilung) ein Assembly ab dem Share nachladen möchte "findet" .NET dieses nicht, resp. sieht dieses nicht.

    Wir investieren seit rund einem halben Jahr Zeit in dieses Problem und sind langsam wirklich etwas ratlos... als Temporär Lösung starten wir die TS-Farmen jede Nach neu...

    Systemumgebung:

    Datenbankserver inkl. FileShare für Programm: Windows Server 2012 /2012 R2/ 2008
    FileShare mit Freigabe im Netzwerk via SMB

    Terminalserver: Windows Server 2012 R2 Terminalserver


    Feststellungen

    • Problem tritt Ausschliesslich auf Windows Server 2012 R2 Terminalserver Sessions auf.
    • Auf diesem TS kann nachher kein Anwender mehr arbeiten (TS-Farmen mit Loadbalancing für die Zugriffe)
    • Auf einem anderen TS kann normal gearbeitet werden in unserer Software
    • Netzlaufwerk ist vorhanden zu diesem Zeitpunkt - Zugriff über Windows-Explorer funktioniert.
    • Problem tritt Random auf - sowohl was Regelmässigkeit betrifft, wie auch welcher TS der Farm betroffen ist
    • Problem tritt bei lokalem Netzwerkzugriff NICHT auf, nur via TS
    • Problem tritt dann auch mit Excel-Files auf, welche "Verweise" auf andere Excel Files haben

    Workarounds im Moment:

    • Wird das Netzlaufwerk neu verbunden, scheint alles wieder für die entsprechende Session zu passen - nicht aber für andere Sessions logischerweise
    • TS Neustart löst das Problem (temporär)

    Versuchte Lösungen:

    • SMB 3.02 deaktivieren (aka wieder via SMB 1)
      Wir hatten vor x Jahren schon mal Mühe bei SMB 2 bezüglich Zugriff
    • Sämtliche Windows Updates vollzogen
    • Zugriff nicht über Laufwerk sondern direkt via UNC

    Eventlog

    Das Eventlog auf dem TS beinhaltet zu diesem Zeitpunkt jeweils 3 Fehlermeldungen:

    1x .NET Runtime (Eigentlicher Absturz)
    Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet.
    Ausnahmeinformationen: System.Runtime.InteropServices.SEHException

    2x Anwendungsabsturzereignisse
    Die erwähnte DLL ist jedoch unterschiedlich - sind jedoch immer .NET Framework oder Windows spezifisch

    --------------------

    Hat jemand einen Tip oder ähnliche Probleme?

    Danke und Gruss
    Roman



    Mittwoch, 16. November 2016 06:54
    |

Alle Antworten

  • Discussion
    Anmelden
    1
    Anmelden

    Hi Roman,

    sind die Terminalserver physisch oder virtuell?
    Wie werden die Netzlaufwerke verbunden - Anmeldeskript, Gruppenrichtlinien, etc.?
    Wenn Gruppenrichtlinien - welcher Modus ist für das Verbinden eingestellt (Aktualisieren, Ersetzen, usw.)?

    Weiterer Workaround: Server täglich nachts neu starten (ist bei Terminalservern unabhängig davon immer ratsam, um "Altlasten" des Tages loszuwerden), tritt das Problem dann immer noch auf?

    Liebe Grüße

    Ben

    _____________________________________

    MCSA Office 365

    MCSA SQL Server 2014

    MCITP Windows 7

    MCSA Windows 8/10

    MCSE Cloud Platform and Infrastructure

    MCSE Messaging

    MCSE Productivity

    _____________________________________

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort. Danke! :-).

    Mittwoch, 16. November 2016 09:25
    |
  • Discussion
    Anmelden
    1
    Anmelden

    Hi,

    Idee von mir:

    1.)

    Mit Procdump einen Dump erstellen lassen wenn die Anwendungen abstürzt.

    Der Aufruf wartet und erstellt die Dumpdatei, die du mit Windows Debugging Tool debuggen kannst!

    (Symbolpath angeben erleichtert die Sache um einiges)

    procdump -h -ma deinprozess.exe c:\Dump\deinprozess.dmp

    2.)

    Mit dem Process Explorer mal Live in den Stack schauen ...vielleicht sieht du hier woran er hängt?

    Hier gibt es auch einen Reiter .NET Assemblies und  .NET Performance)

    3.)

    Überprüft doch mal die Systemvariablen (TS und auf dem Client) -> auch das geht über den ProcessExplorer (-> Reiter Enviroment))

    4.)

    Mit dem Process Monitor ein Log erstellen. Filter auf eure Anwendung und hier mal schauen ob euch etwas auffällt. (Tip: Reiter Tools->Count Occurrences und bei Colums Result wählen)

    Du kannst die Dateien gerne mal in die Cloud laden und den Link posten.Dann schau ich gern auch mal drauf.

    ______________________________________________________

    In allen Anwendungen kann man einen Link zum Symbolsserver einrichten um ausführliche Informationen zu bekommen. Hier kann man die folgenden Einstellungen treffen.

    _______________________________________________________

    dbghelp.dll

    C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbghelp.dll (bei installierten Debugtools (x64) )

    oder 

    C:\Windows\system32\dbghelp.dll (default)

    Symbols path

    SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

     

    Bis dann, Toni! Wenn Dir meine Antwort hilft dann markiere sie bitte als Antwort! Vielen Dank!



    • Bearbeitet tonibert Mittwoch, 16. November 2016 10:26
    Mittwoch, 16. November 2016 10:21
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hoi  Ben & Toni

    Danke schon mal für die prompten Reaktionen!

    @Ben - zu deinen Fragen

    • Die Terminalserver sind virtuell (Hyper-V)

    • Mapping der Netzlaufewerke wird via Loginscript (vb-script eingebunden über LoginScript) gemacht.
      --> Grundsätzlich wird bei jeder Anmeldung gelöscht und neu verbunden (NET USE)

    @Toni

    1. Dein Vorschlag bezüglich ProcDump ist gut, haben wir aber eben bereits gemacht (Entwicklungsabteilung).
      Problem hierbei ist rein das optimierte "Nachladen" von dlls  - das ist pures .NET Framework und lässt sich so  nicht direkt tracen gem. Entwickler.
    2. wurde bereits gemacht - leider Erfolglos - Problem ist der eigentliche .NET Runtime Absturz gem. meiner Beschreibung :(
    3. werde ich prüfen!
    4. werde ich prüfen!

    Gruss und Danke

    Roman

    Donnerstag, 17. November 2016 13:00
    |
  • Discussion
    Anmelden
    0
    Anmelden
    Kann man, wenn das Problem auftritt, noch über den Explorer auf die Netzlaufwerke zugreifen oder geht das auch nicht mehr?

    Liebe Grüße

    Ben

    _____________________________________

    MCSA Office 365

    MCSA SQL Server 2014

    MCITP Windows 7

    MCSA Windows 8/10

    MCSE Cloud Platform and Infrastructure

    MCSE Messaging

    MCSE Productivity

    _____________________________________

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort. Danke! :-).

    Freitag, 18. November 2016 09:09
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hoi Ben

    Kann man - wird aber visuell als disconnected (Rotes Kreuz) angezeigt.

    Montag, 21. November 2016 13:44
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Moin,

    werden die Freigaben direkt oder über DFS verbunden?

    Liebe Grüße

    Ben

    _____________________________________

    MCSA Office 365

    MCSA SQL Server 2014

    MCITP Windows 7

    MCSA Windows 8/10

    MCSE Cloud Platform and Infrastructure

    MCSE Messaging

    MCSE Productivity

    _____________________________________

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort. Danke! :-).

    Dienstag, 22. November 2016 11:01
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Moin,

    werden die Freigaben direkt oder über DFS verbunden?

    Das ganze wird über ein Login-Script direkt verbunden sprich kein DFS

    Freitag, 25. November 2016 06:46
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Roman,

    ich melde mich hier als Leidensgenosse, da deine Probleme sehr stark meinen Problemen beim Kunden ähneln. Auch unsere Software wird über ein Netzlaufwerk auf den Windows-PC-Arbeitsplätzen oder TS zur Verfügung gestellt. Wir beobachten ebenfalls, dass das Problem überwiegend auf TS auftritt. Windows-PC-Arbeitsplätze im gleichen Netzwerk, die auch auf das gleiche Netzlaufwerk zugreifen, betrifft dieses Problem nicht.

    Eine besonderer Eintrag im EventLog sticht extrem hervor, welches angeblich auf Probleme in der Netzwerkverbindung hinweisen. Es geht um folgenden Eintrag:

    Protokollname: Application
    Quelle:        Application Error
    Datum:         12.01.2017 13:27:26
    Ereignis-ID:   1005
    Aufgabenkategorie:(100)
    Ebene:         Fehler
    Schlüsselwörter:Klassisch
    Benutzer:      Nicht zutreffend
    Computer:      XXX.XXX.local
    Beschreibung:
    Aus einem der folgenden Gründe kann nicht auf die Datei "" zugegriffen werden: Es besteht ein Problem mit der Netzwerkverbindung, dem Datenträger mit der gespeicherten Datei bzw. den auf dem Computer installierten Speichertreibern, oder der Datenträger fehlt. Das Programm XXX.exe wurde wegen dieses Fehlers geschlossen.

    Kannst du den gleichen Eintrag bei deinen Kunden feststellen?

    Da wo die Probleme akut waren, haben wir das Programmverzeichnis, welches auf dem Netzlaufwerk liegt, lokal auf den Terminalserver verschoben. Danach lief das Programm deutlich stabiler. Ist sowas mit deiner Software möglich?

    Nichtsdestotrotz wäre die Ursache dieser Fehler interessant.

    Gruß Philip

    Donnerstag, 2. Februar 2017 13:30
    |
  • Discussion
    Anmelden
    1
    Anmelden

    kann es ggf. hiermit zu tun haben?

    https://support.microsoft.com/en-us/help/2536487/applications-crash-or-become-unresponsive-if-another-user-logs-off-a-remote-desktop-session-in-windows-server-2008-or-windows-server-2008-r2

    Gilt auch für Server 2012R2 und ist (angeblich) mit Server 2016 behoben.

    Gruß Andrea

    Je grösser die Insel des Wissens, desto grösser die Küste der Verzweiflung...

    Freitag, 10. Februar 2017 09:37
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Frage: Ist der Server mit dem Share in derselben Domäne ? Falls ja, sollte man eine CIFS-Dienst-Delegierung (der Terminalserver vertraut den Share) erstellen. Dann wird für die Auth. Kerberos benutzt. Vielleicht hilft das...

    DSA.msc aufrufen-->Eigenschft des beteiligten Computers-->Delegierung-->Computer bei Delegierungen angegebener Dienste vertrauen-->Nur Kerberos-->Hinzufügen-->anderen Computer auswählen-->Diensttyp cifs.

    Freitag, 10. Februar 2017 10:19
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Es reicht nicht aus, im Windows Tresor die Cerentials zu hinterlegen. Daher greift auch ohne Delegation der Powershell-befehl

    Export-VM -Name <VM-Name> -Path "\\<ip-Adresse>\share"

    nicht und produziert einen Zugriffsrechtefehler..

    Freitag, 10. Februar 2017 10:22
    |
  • Discussion
    Anmelden
    0
    Anmelden

    kann es ggf. hiermit zu tun haben?

    https://support.microsoft.com/en-us/help/2536487/applications-crash-or-become-unresponsive-if-another-user-logs-off-a-remote-desktop-session-in-windows-server-2008-or-windows-server-2008-r2

    Gilt auch für Server 2012R2 und ist (angeblich) mit Server 2016 behoben.

    Gruß Andrea

    Danke für den Artikel. Die von Microsoft beschriebene Lösung halte ich für bedenklich und Gewinnorientiert. Mir stellt sich die Frage, warum die Lösung für den 2016er nicht als Update für die alten Betriebssysteme zur Verfügung gestellt wird!?

    Gruß Philip

    Mittwoch, 15. Februar 2017 10:26
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Frage: Ist der Server mit dem Share in derselben Domäne ? Falls ja, sollte man eine CIFS-Dienst-Delegierung (der Terminalserver vertraut den Share) erstellen. Dann wird für die Auth. Kerberos benutzt. Vielleicht hilft das...

    DSA.msc aufrufen-->Eigenschft des beteiligten Computers-->Delegierung-->Computer bei Delegierungen angegebener Dienste vertrauen-->Nur Kerberos-->Hinzufügen-->anderen Computer auswählen-->Diensttyp cifs.

    Danke für den Tipp. Klingt für mich plausibel, jedoch sind trotz konfigurierter Delegierung die Abstürze weiterhin vorhanden.

    :(

    Gruß Philip

    Mittwoch, 15. Februar 2017 10:28
    |