Internetverbindung geht nicht nach W10 Update (Build 17134.48-Mai 2018)

[4dk2]

Moin zusammen,
habe nen gravierendes Problem.
Mit dem neuen W10 Update (Mai-2018) / Windows 10, Version 1803
Funktionieren Internet-Verbindungen von Programmen, die von Netzlaufwerken gestartet werden nicht mehr.

Beispiel:

Delphi-Quellcode:

  try
    s:=FHttpObj.Get('https://www.google.de'); //indy...
      if length(s)>0 then
        result:=true;
    end;
  except on e:exception do
   begin
    showmessage(e.Message);
    result:=false;
   end;
  end;

Starte ich das von lokal geht es, lege ich es auf ein Netzlaufwerk, kommt: Socket-Fehler # 10022 Ungültiges Argument.
DLLs (OpenSSL) sind Lokal und Netzlaufwerk gleich, der Fehler passiert sogar wenn ich einfach die Ausgabe der Exe auf Netzlaufwerk lege und Debugging starte.

Irgendjemand ne Idee?

[4dk2]

Zwischeninfo:
ist das Netzlaufwerk ein anderes W10 (aber uralte Vmware) geht es.
Denke hat was mit SMB2/3 zutun.
beim Fehlerfall hab ich bisher Win2003 Server (ja weiss uralt, aber ist nur Netzlaufwerk) und Linux getestet.

[4dk2]

ok, liegt daran, dass es Netzlaufwerke sind, die mit SMBv1 laufen.
nen Workarround gibt es nicht, lediglich die Möglichkeit auf SMBV2/V3 umzusteigen.

Ich find die hätten aber eher ne Warnung einbauen sollen, beim verbinden vom Smb1 Laufwerk, das dies und das nicht geht.

[himitsu]

Haben mehrere das Problem, wo man eventell die bereits genannten Dinge ausprobieren könnte.
Socket-Error 10022

Interessant Witzig ist auch der Zusatz bei der Fehlerbeschreibung, also dass der Fehler auch was ganz Anderes bedeuten kann. :stupid:
https://msdn.microsoft.com/de-de/lib...(v=vs.85).aspx

[Der schöne Günther]

Zitat:

Zitat von Der schöne Günther (Beitrag 1401819)

Da Microsoft von SMBv1 schon seit 2014 abrät, dann WannaCry passierte und es schon seit dem letzten Update vor über einem halben Jahr schon standardmäßig nicht mehr bei Neuinstallationen dabei ist […]

Das stimmt, so eine Messagebox hätte auch bei Anwendern sicher für mehr Verunsicherung gesorgt, die hätten dann bei ihrem Hersteller angerufen und die hätten dementsprechend Druck gehabt. 8-)

[4dk2]

Zitat:

Zitat von himitsu (Beitrag 1402933)

Haben mehrere das Problem, wo man eventell die bereits genannten Dinge ausprobieren könnte.

jo hab schon vieles ausporbiert :-D
Kompatiblität auf W8 stellen usw. aber geklappt hat nix.

Meine Lösung für die Kunden. Auf vorherige W10 Version gehen und Server Aufrüsten :roll:

[4dk2]

Zitat:

Zitat von Der schöne Günther (Beitrag 1402934)

Zitat:

Zitat von Der schöne Günther (Beitrag 1401819)

Da Microsoft von SMBv1 schon seit 2014 abrät, dann WannaCry passierte und es schon seit dem letzten Update vor über einem halben Jahr schon standardmäßig nicht mehr bei Neuinstallationen dabei ist […]

Das stimmt, so eine Messagebox hätte auch bei Anwendern sicher für mehr Verunsicherung gesorgt, die hätten dann bei ihrem Hersteller angerufen und die hätten dementsprechend Druck gehabt. 8-)

also zwei Kunden haben direkt bei der Telekom angerufen, weil die dachten die haben was verbockt :stupid:

[Rollo62]

Dies ist vielleicht das gleiche Thema.

Sind davon wirklich nur Delphi-Apps betroffen ?

Rollo

[Dalai]

Zitat:

Zitat von 4dk2 (Beitrag 1402937)

Meine Lösung für die Kunden. Auf vorherige W10 Version gehen und Server Aufrüsten :roll:

Oder in OptionalFeatures.exe das SMB1-Protokoll aktivieren.

Grüße
Dalai

[4dk2]

Zitat:

Zitat von Rollo62 (Beitrag 1402992)

Dies ist vielleicht das gleiche Thema.

Sind davon wirklich nur Delphi-Apps betroffen ?

Rollo

Nein. Generell alle Apps die Winsockets benutzen.

Zitat:

Zitat von Dalai (Beitrag 1402997)

Zitat:

Zitat von 4dk2 (Beitrag 1402937)

Meine Lösung für die Kunden. Auf vorherige W10 Version gehen und Server Aufrüsten :roll:

Oder in OptionalFeatures.exe das SMB1-Protokoll aktivieren.

Das bringt den Support Clientseitig für SMB1, jo, ohne den kommt das problem eh nicht, bzw du nicht auf den SMB1-Server:wink:

[himitsu]

Kann es sein, dass auf diesem SMB ein XCOPY in einer CMD auch nicht mehr geht?
Wir bekommen da gerade ein Zugriff verweigert, aber es könnte eventuell auch an einem krankhaft übersicher eingestellten Windows liegen.

[jobo]

Mit dem Update jüngsten W10 Update habe ich auf einem Rechner das Phänomen, dass eine Datenbankverbindung nicht mehr aufgebaut werden kann, wenn die Exe auf einem Windows Share liegt.
Nach einem Verschieben der Anwendung auf lokal geht es (also 100% gleiche Anwendung, gleiches System).
Mir reicht das derzeit als Workaround.

Jedenfalls scheint es wie gesagt nicht nur ein SMB Versionsproblem zu sein, sondern genereller Natur, z.B. win socket wie schon gesagt.

Interessant wäre mal, wie sich das vergleichsweise bei Onedrive verhält. Ich nutze das überhaupt nicht und werde es nur aus Neugier auch nicht aktivieren.

[jaenicke]

Fehlschlagen tut hier direkt die Winsock-API-Funktion socket, sprich es passiert direkt bei der Erstellung des Socket bevor der überhaupt initialisiert wird. Eine Lösung haben wir nicht gefunden, wir gehen aber davon aus, dass es sich um einen Bug handelt. Wir vermuten, dass es hiermit zu tun hat:
https://support.microsoft.com/de-de/...date-kb4284835

Zitat:

Problembeschreibung:
Manchen Benutzern, die Windows 10, Version 1803 ausführen, wird möglicherweise die Fehlermeldung „Ein ungültiges Argument wurde angegeben“ angezeigt, wenn sie über einen freigegebenen Order mithilfe des SMBv1-Protokolls auf Dateien zugreifen oder Programme ausführen.

Problemumgehung:
Aktivieren Sie wie in KB2696547 beschrieben SMBv2 oder SMBv3 sowohl auf dem SMB-Server als auch auf dem SMB-Client.

Microsoft arbeitet an einer Lösung, die zu einem späteren Zeitpunkt im Juni verfügbar sein wird.

Ein Workaround ist auch, dass die Anwendung per Skript nach z.B. %TEMP% kopiert und von dort gestartet wird. Die Anwendung kann sich auch selbst dorthin kopieren und starten.

Das ist auch der Grund weshalb wir von Anfang an von einem Bug ausgegangen sind:
Als Sicherheitsfeature müsste diese Blockade auch für durch den Prozess gestartete Prozesse gelten, sonst macht es ja keinen Sinn.

[jobo]

Zitat:

Zitat von jaenicke (Beitrag 1405309)

Als Sicherheitsfeature müsste diese Blockade auch für durch den Prozess gestartete Prozesse gelten, sonst macht es ja keinen Sinn.

Das Argument ist richtig, aber man könnte es an dutzenden Stellen anwenden. Meistens sehen "Verbesserungen" doch so aus, dass es ein Hase / Igel Problem ist und häppchenweise behoben wird. Oder nach dem 9:1 Nutzen:Aufwand Prinzip.
Man kann mit solchen Dingen die Anwender auch "subtil" in eine bestimmte Richtung drängen. Bspw. wenn Verfahren (Deploy) genutzt werden, die auf klassischen Netzwerkmechnismen (Netzwerklaufwerk) beruhen und etabliert sind, was ist ein naheliegender Workaround? Cloudspeicher plus lokale Kopie.

[jaenicke]

Zitat:

Zitat von jobo (Beitrag 1405319)

Meistens sehen "Verbesserungen" doch so aus, dass es ein Hase / Igel Problem ist und häppchenweise behoben wird. Oder nach dem 9:1 Nutzen:Aufwand Prinzip.

Nur ist es ja keine Verbesserung, wenn alle Virenautoren (wenn das denn die Intention wäre) einen leichten Workaround haben, aber alle Nutzer, die das Problem haben, erst einmal damit gegen die Wand fahren. ;-)

[jobo]

Zitat:

Zitat von jaenicke (Beitrag 1405333)

Nur ist es ja keine Verbesserung, wenn alle Virenautoren (wenn das denn die Intention wäre) einen leichten Workaround haben, aber alle Nutzer, die das Problem haben, erst einmal damit gegen die Wand fahren. ;-)

Damit wiederholst Du Dein Argument. Demnach wäre nichts eine Verbesserung, was keine 100%ige und dauerhafte Lösung liefert. So funktioniert der Softwaremarkt aber (leider) selten*.

Außerdem liegt ja die Intention (Bug/Feature) der ganzen Sache im Dunkeln. Wer hier also was verbessern will, ist unbekannt. Ich habe nur 2 Aspekte genannt, die man in Betracht ziehen könnte.

Ansonsten würde ich gerade MS erstmal unterstellen, dass nahezu keine einzige Neuheit, Umgestaltung, .. einfach nur erfolgt, weil es halt geht bzw. machbar ist. Eher umgekehrt dürfte es sich meistenteils um planvolles oder sogar strategisches Vorgehen handeln.

*ich habe keine Lust über die Rate zu streiten.

[sh17]

Das Problem tritt auch auf einer Synology-Freigabe mit aktiviertem SMB2 auf.

[BerndS]

Hallo
Wir konnten das Problem lösen, indem wir auf dem W10 PC das Windows-Features Unterstützung für die SMB 1.0/CIFS-Dateifreigabe deaktiviert haben.
Die Freigabe zeigte hier auf eine Windows 7 PC. Anscheinend ist SMB1 bei Windows 7 noch die erste Wahl.

[jaenicke]

Zitat:

Zitat von BerndS (Beitrag 1405431)

Wir konnten das Problem lösen, indem wir auf dem W10 PC das Windows-Features Unterstützung für die SMB 1.0/CIFS-Dateifreigabe deaktiviert haben.
Die Freigabe zeigte hier auf eine Windows 7 PC. Anscheinend ist SMB1 bei Windows 7 noch die erste Wahl.

Es wird immer das höchste verfügbare Protokoll benutzt. SMB 2 war ja offenbar auf dem Windows 7 PC aktiv, sonst hätte ohne SMB 1 die Freigabe ja nicht mehr erreichbar sein können.

Daraus folgt, dass dann offenbar das reine Vorhandensein von SMB 1 unter Windows 10 das Problem auslöst, auch wenn es konkret zum Zugriff gar nicht verwendet wird. :shock:

Naja, hoffen wir einfach mal, dass der angekündigte Fix bald kommt.

[BerndS]

@jaenicke

Das immer das höchste verwendet, wird hätte ich auch erwartet. Auf jeden Fall war es in unserem Fall nicht so.
Ich hatte keinen Zugriff auf den Windows 7 PC und der "Techniker" vor Ort konnte mit dem Begriff SMB nichts anfangen. Möglicherweise war dort etwas falsch konfiguriert oder wichtige Updates nicht installiert. Auf jeden Fall war es so, dass das Abschalten auf dem W10 PC das Problem gelöst hat.

[jaenicke]

Der Fix ist erschienen:
https://support.microsoft.com/de-de/...date-kb4284848

Ich habe für unsere Anwendungsfälle verifiziert, dass die Probleme gelöst sind.

Zitat:

Zitat von BerndS (Beitrag 1405505)

Das immer das höchste verwendet, wird hätte ich auch erwartet. Auf jeden Fall war es in unserem Fall nicht so.

Doch, schon, aber wie wir mittlerweile auch verifiziert hatten reichte das bloße Vorhandensein von SMB 1, dass es nicht funktionierte, selbst wenn es nicht für die konkrete Verbindung verwendet wurde. :shock: