[English]Es sieht so aus, als ob die im November 2022 von Microsoft veröffentlichten Windows-Updates zu Problemen beim Zugriff auf SQL-Datenbanken führen können. Dann löst der ODBC-Treiber einen Datenbank-Zugriffsfehler aus. Laut Microsoft sind alle noch unterstützten Windows-Versionen (sowohl Clients als auch Server) von diesem Problem betroffen. Eine Lösung für dieses Problem gibt es noch nicht.
Anzeige
Microsoft hat das Problem zum 5. Dezember 2022 im Windows Release Health Statusbereich (beispielsweise von Windows 11 22H2) im Beitrag Database connections using Microsoft ODBC SQL Server driver might fail bestätigt. Dort heißt es:
Nach der Installation [des Updates xxxx] können Anwendungen, die ODBC-Verbindungen mit dem Microsoft ODBC SQL Server-Treiber (sqlsrv32.dll) für den Zugriff auf Datenbanken verwenden, möglicherweise keine Verbindung herstellen.
Möglicherweise erhalten Sie eine Fehlermeldung innerhalb der Anwendung oder Sie erhalten eine Fehlermeldung von SQL Server, wie z. B.
Das EMS-System hat ein Problem festgestellt
Meldung: [Microsoft][ODBC SQL Server Driver] Protocol error in TDS Streamoder
Message: [Microsoft][ODBC SQL Server Driver]SQL Server Driver]Unknown token received from SQL Server
Betroffen sind folgende Windows Client-Versionen, wenn das passende November 2022-Update installiert wurde:
- KB5019980: Windows 11 Version 22H2
- KB5019961: Windows 11 Version 21H2
- KB5019959: Windows 10 Version 20H2-22H2
- KB5019966: Windows 10 Enterprise LTSC 2019
- KB5019964: Windows 10 Enterprise LTSC 2016
- KB5019970: Windows 10 Enterprise 2015 LTSB
- KB5020023, KB5020010: Windows 8.1
- KB5020000, KB5020013: Windows 7 SP1
sowie folgende Windows Server-Versionen:
- KB5019081: Windows Server 2022
- KB5019966: Windows Server 2019
- KB5019964: Windows Server 2016
- KB5020023, KB5020010: Windows Server 2012 R2
- KB5020009, KB5020003: Windows Server 2012
- KB5020000, KB5020013: Windows Server 2008 R2 SP1
- KB5020019: Windows Server 2008 SP2
Um zu überprüfen, ob der Treiber für den Microsoft SQL-Server betroffen ist, lässt sich in einer administrativen Eingabeaufforderung der folgende Befehl eingeben.
Anzeige
tasklist /m sqlsrv32.dll
Taucht der Prozess auf, und wird der Fehler gemeldet, ist das System vom Problem betroffen. Bisher gibt es (außer das Update zu deinstallieren) keinen Fix. Microsoft arbeitet an diesem Problem und will dieses in Zukunft per Update beheben. (via)
Ergänzung: Microsoft schlägt den in den nachfolgenden Kommentaren skizzierten Workaround (Austausch des Treibers) jetzt auch offiziell vor, siehe Windows: Microsoft Workaround für ODBC-Verbindungsprobleme (5. Jan. 2023).
Ähnliche Artikel:
Patchday: Windows 10-Updates (8. November 2022)
Patchday: Windows 11/Server 2022-Updates (8. November 2022)
Windows 7/Server 2008 R2; Windows 8.1/Server 2012 R2: Updates (8. November 2022)
Anzeige
Lösung ist, den SQL-Driver 17 zu installieren und zu verwenden (alte ODBC-Verbindung löschen und mit dem neuen Treiber anlegen).
Der ist sowieso besser, weil etwas schneller. Native Client würde auch funktionieren, ist aber eigentlich zu alt.
Wir kennen das Problem seit ca. 3 Wochen, tritt nicht sofort auf sondern ist wohl u.a. von der Speicherauslastung abhängig. Wenn der Fehler aber da ist, bleibt er. Unsere Anwendung friert dann völlig ein und muss abgeschossen werden.
Moep! Ich hab genau zu der Zeit unseren SQL-Cluster abgelöst und wir dachten es liegt daran. Der Fehler ist hier nur unter SQL 2019 aufgetreten und nicht unter SQL 2014. Kann aber auch Zufall gewesen sein. Wir sind dann zu der selben Lösung gekommen und haben SQL-Driver 17 verteilt.
Das Neuanlegen der Datenquelle mit anderem Treiber klappt bei unserem Problemkind aus dem Hause Estos im Zusammenspiel mit SQL Server Express leider nicht, die Serveranwendung erstellt die Datenquelle bei jedem Start neu, wieder mit dem alten Treiber SQL Driver. Der Tasklist-Befehl liefert zwar kein Ergebnis, wir müssen aber trotzdem davon ausgehen, dass die Anwendung sich über diesen Treiber mit dem SQL-Server verbindet, denn die Probleme kommen und gehen eindeutig mit Installation der Windows Server 2019-Updates, wenn auch erst nach einiger Zeit problemlosen Betriebs.
So ganz blicke ich das jetzt noch nicht, wir haben Systeme auf denen der ODBC Treiber 11 oder 13 und 17 (Achtung, boolsche Verknüpfung beachten!!!) installiert ist, je nach dem ob das ein Win 10 Client oder ein Server 2019 ist, ist eine sqlsrv32.dll vom 4.11.2022 (Version 10.00.14393.5501) oder 9.11.2022 (Version 10.00.19041.2251) aktiv. Kann man übrigens am einfachsten rausbekommen, wenn man im Startmenü "odbc" eintippt und dann "ODBC Datenquellen (64 Bit)" auswählt und dann in den Treiber-Tab wechselt.
Probleme haben wir jedenfalls nicht. Vielleicht sind wir einfach schon lang genug auf der 17er Version, dass alle Verbindungen schon damit angelegt wurden.
Die von dir erwähnten Treiber verwenden jeweils eine eigene DLL wie z.B. MSODBCSQL13.DLL oder MSODBCSQL17.DLL (den 11er Treiber habe ich nicht installiert).
Die sqlsrv32.dll, die auf euren Systemen als '4.11.2022 (Version 10.00.14393.5501)' oder '9.11.2022 (Version 10.00.19041.2251)' vorliegt, hat mit den von dir genannten Treibern nichts zu tun.
Sie wird seit Ewigkeiten von Windows selbst bereitgestellt (und vielleicht auch mal aktualisiert? Obwohl sie ja seitens Microsoft als Legacy deklariert ist).
Interessant, aber oben und bei MS wird "tasklist /m sqlsrv32.dll" als Indikator genannt, um zu sehen, dass man betroffen ist. Stimmt das etwa nicht?
Der Befehl 'tasklist…' zeigt nur an, ob die Standard-dll den fehlerhaften Stand hat. Übeltäter ist Version 10.00.19041.2251
Welcher Treiber wirklich benutzt wird, wird in der ODBC-Verbindung festgelegt.
@1ST1: Doch, das stimmt schon. Denn nur der Legacy-Treiber (also der den man nicht installieren muss, weil er von Windows mitgeliefert wird) ist ja scheinbar betroffen, und der wird ja durch die Datei sqlsrv32.dll repräsentiert.
Im von dir erwähnten "ODBC Datasource Administrator" wird dieser auf der Karteikarte "Treiber" mit dem Namen "SQL Server" aufgeführt. Die anderen heißen dort "ODBC Treiber * für SQL Server". Dort sieht man jeweils weiter rechts auch die verwendete DLL.
Ja, so weit vermute ich das auch schon. Jetzt vermute ich mal, sobald ich also einen SQL Treiber Version 17 installiert habe, wird die Standard-sqlsrv32.dll garnicht mehr benutzt? Und die 5 Tage ältere 10.00.14393.5501 ist nicht betroffen?
Offenbar ist diese Methode nicht zuverlässig. Die Probleme treten eindeutig im Zusammenhang mit den letzten beiden Windows Server 2019-Updates (November/Dezember) auf, der Tasklist-Befehl liefert aber keine Ausgabe. Wir sehen in der betreffenden Anwendung aus dem Hause Estos im Process Explorer Strings und DLLs/Handles-Referenzen, die auf den problematischen alten SQL-Driver verweisen, außerdem legt die betreffende Anwendung eine entsprechende ODBC-Datenquelle bei jedem Start immer wieder neu an, auch wenn man sie manuell ändert.
@1ST1: Ich kann nicht mehr noch verschachtelter antworten, deshalb hier. ;-)
Nein, so einfach ist das nicht. Welcher der installierten ODBC-Treiber tatsächlich von einer Anwendung verwendet wird bestimmt diese i.d.R. selbst.
Aber da gibt es unterschiedliche Herangehensweisen.
Es kann sein, dass eine Anwendung eine zuvor angelegte Datenquelle verwendet. Eine solche Datenquelle kann z.B. im "ODBC Datasource Administrator" erstellt werden. Z.B. als Registry-Eintrag oder aber auch als Datei. In dieser Datenquelle stünde dann, welcher Treiber verwendet werden soll, und auch welcher SQL-Server, welche Datenbank usw.
Es kann aber auch sein, dass eine Anwendung gar keine zuvor an solch zentraler Stelle definierte Datenquelle verwendet, sondern dies mittels eines ODBC-Connection-Strings intern für sich definiert. In diesem String, den die Anwendung dann zum Herstellen einer Verbindung zu einem SQL Server vorgibt, stünde dann welcher ODBC-Treiber, SQL Server, Datenbank usw. zu verwenden sind.
Vielen Dank für diese weiterführende Aufklärung, für jemanden, der sowas gelegentlich nur aufsetzt und bereitstellt, ohne sich um den "Inhalt" kümmern zu müssen, erklären sich so einige Vorgänge der letzten Wochen. Eine intern eingesetzte Anwendung mit SQL-Backend bekam just 3 Tage nach dem Update-Release-Tag ein "außerhalb des regulären Update-Zyklus"-Update, wahrscheinlich wurde hier einfach nur der Connection-String angepasst, da das Update nicht sonderlich groß war und mit separaten ODBC-Datenquellen wird nicht gearbeitet. Die Phänomene vor Update-nach-Update waren aber ähnlich, häufiges Einfrieren der ganzen Anwendung vor allem zum Feierabend hin.
@Henry Barson:
Haben Sie vielleicht die KB Nummer von dem OOB Update?
Danke!