[Doodle]

Zitat (d4rkn3ss4ev3r: 13. Dezember 2015 - 21:14)

Ihr könntet mal wie ich in diesen Beitrag gepostet habe, den Tipp mit den MiniWAN Adaptern prüfen.

Habe ich, hat aber nix gebracht.

[Doodle]

Geht munter weiter. Lässt sich auch nicht mehr reparieren.

[DanielDuesentrieb]

Was steht denn in den Eigenschaften der Netzwerkkarte? Da sind doch eigentlich alle Protokolle aufgeführt. Fehlt da denn eins?

Vielleicht zur allgemeinen Lösung: Tritt das Problem immer auf oder nur bei einem Upgrade von Windows 7 und später ohne Neuinstallation oder auch bei einer frischen Neuinstallation?

Erst nach dem Upgrade auf 1511 oder auch bei einem frischen ISO mit 1511?

Hoffe, ich bekomme den Mist nicht .

Dieser Beitrag wurde von DanielDuesentrieb bearbeitet: 15. Dezember 2015 - 22:37

[DK2000]

Es ist ja nicht so, dass das Protokoll als ganzes verschwindet, jedenfalls bei mir nicht. Bei mir scheint sich da nur an den Einstellungen etwas zu ändern:

Es fehlen die für die Netzwerkkonnektivität erforderlichen Windows Sockets-Registrierungseinträge.

Da scheint sich nur etwas in der Registry zu verstellen und das stößt ihm quer auf. Aber was und warum, keine Ahnung. Im Moment läuft es wieder.

[dennisberlin]

Hey Folks.
Bei mir tritt der Fehler seit heute auch auf und ich konnte bisher mit keinem der aufgeführten Lösungsansätze Abhilfe schaffen.
Updates sind alle installiert, Netzwerkadapter zurückgesetzt, reset via CMD...
Meine Güte, dass kann nicht deren Ernst sein!!!!

Edit.
Ich lade gerade nochmal via MediaCreationTool alle Updates.
Die Hoffnung stirbt zuletzt.

Achja. Bei mir funktioniert das WLAN einwandfrei, nur die LAN Verbindung kommt nicht mehr zustande (..auf dem Computer fehlt mindestens ein Netzwerkprotokoll..)

update:
bei mir hat das Durchführen des Updates via MediaCreationTool das Problem beseitigt. Allerdings bin ich jetzt von Version 1511 (Build 10586.29) zurück auf Version 1511 (Build 10586.0)

Ich hoffe das Problem stellt sich nicht über Nacht wieder her.

Berichte morgen..

Neu:
Auch nach mehreren Restarts funktioniert jetzt alles wieder wie es muss.

Dieser Beitrag wurde von dennisberlin bearbeitet: 17. Dezember 2015 - 13:03

[DanielDuesentrieb]

Um welche Netzwerkkarten sprechen wir dann? Sind die ggf. alle von Intel oder doch querbeet? Ältere oder nur neueren Typs?

[DK2000]

So richtig nachvollziehbar ist das alles nicht. Da wird zwar ein Diagnoseprotokoll angelegt, aber so wirklich schlau werde ich daraus auch nicht:

Spoiler

NetConnection LowHealth diagnosis status 3 [DS_INDETERMINATE] HRESULT 0 [4 ms] description: Möglicherweise liegt ein Problem mit dem Adapter "Ethernet0" vor.

IpPath LowHealth diagnosis status 1 [DS_CONFIRMED] HRESULT 0 [1 ms] description: Der Computer ist nicht richtig konfiguriert. Es gibt keine verfügbare Route zwischen den zwei Computern.

GetClassFactory failed for NetworkAccessProtection. The HC is not registered with NDF

Diagnose Winsock (v1.0). LowHealth : initial state 0, ATTRIBUTES: protocol=6; localaddr=AF_UNSPEC;remoteaddr=AF_UNSPEC;

Details zu WinsockHelperClass Diagnose: 

Verify that base transport protocol entries exist in the Winsock catalog

Die Diagnosephase des Vorgangs wurde abgeschlossen. Die folgende Reparaturoption wurde angeboten: 

Hilfsklassenname: Winsock

Zugrunde liegende Ursache: Auf diesem Computer fehlt mindestens ein Netzwerkprotokoll.
Es fehlen die für die Netzwerkkonnektivität erforderlichen Windows Sockets-Registrierungseinträge. 

GUID der zugrunde liegenden Ursache: {4cc189f9-4afd-4a1e-91c9-90881165dd3b} 

Reparaturoption: Stellen Sie für Netzwerkprotokolle die Standardeinstellungen wieder her.
Auf dem Computer fehlt mindestens eine Netzwerkeinstellung. 

Reparatur-GUID: {9742229c-d71a-4710-91a8-5afabe971268} 

Erforderliche Zeit für die Reparatur in Sekunden: 1 

Für die Reparatur erforderlicher Sicherheitskontext: 26

Schnittstelle:  ({00000000-0000-0000-0000-000000000000}).

Zu reparieren schaft er es aber nicht. Und warum es auftritt, keine Ahnung. Irgendetwas läuft da schief.

Das Diagnoseprotokoll findet man unter C:\Users\<User>\AppData\Local\Diagnostics\ in den entsprechenden Unterordner. Öffnen kann man es mit der Ereignisanzeige.

Bei mir ist es eine virtuelle Karte (Intel® 82574L Gigabit Network Connection). Damit hat das aber offensichtich nichts zu tun, da das Problem auch auf realen Installationen auftritt.

Bekomme das im Moment absolut nicht nachvollzogen, wann und warum das Problem auftritt. Es ist plötzlich wieder da. Erst dachte ich, das hängt mit dem CryptDNS Teil da zusammen, aber daran lag es wohl nicht.

[Sturmovik]

Ich hab mal eben ein bischen bei der Konkurrenz gespickt.
Laut einem Thread bei DrWindows ist das unabhängig vom Typ des Netzwerkadapters.

Und bei MS findet sich diese "Lösung" answers.microsoft.com

KB3120677 soll das Problem angeblich beheben, sagt borncity

Dieser Beitrag wurde von Sturmovik bearbeitet: 16. Dezember 2015 - 16:03

[DK2000]

Die Sache mit KB3120677 hatte ich da schon in Beitrag #5 erwähnt, da das ja angeblich die Lösung sein soll. KB3120677 ist bei mir aber installiert und dennoch tritt das Problem auf. Unregelmäßig.

Auch die Sache mit den Netzwerkprotokollen löschen scheint da nur temporär zu helfen.

Das Ganze muss noch einen anderen Grund haben.

[Doodle]

Eine zusätzliche Variante: Jetzt ist zwischenzeitlich auch das Standardgateway nicht verfügbar.

Danke Microsoft.

[djesx]

Was sagt denn das Eventlog? Gab's evtl. mit dem Treiber schon direkt nach dem zum Upgrade Fehlermeldungen?
Sowas wie "Treiber konnte nicht erfolgreich migriert werden", also außer den normalen logs wie zb "konnte nicht gestartet werden...."? Hatte ich auch mal mit 'ner sehr frühen Preview und einer Realtek 8110 & 8169.

Mache eigentlich nur clean install, aber wollt mal das in-Place Upg. testen.. Lösung gabs bei mir nicht.. alle sonst (auch in W10 - clean install) funzenden treiber gingen dann nicht mehr, und mit nem versuch aus nem Forum (einen registry key löschen) hat zum BSOD während des Bootens geführt..

Alles weitere hätte zu lange gedauert, bin dann wieder auf meine Clean installierte partition und hab ne neu-installation gemacht ... heute bin ich allerdings auf die 11082 via INPLACE-Upg, und alle NIC´s laufen

Hatte bisher nur Visual Studio, Office und RSAT-Tools installiert, da hat das meine alte, alte OS-platte in 1,5 Std. migriert!!! Hab ich da vorhin Was mit DNScrypt gelesen? k.a. wie tief das an die hardware geht, kann natürlich auch zu "issues" geführt haben. Aber encrypted DNS - das brauchst eh nicht!! mit DNS Server hack gibts eigentlich keine Angriffe auf Nutzer. Ist eher ein extra gefahrenpotential, man könnte mal so nen DNScrypt server hacken^^ .. UND wenn es mal Änderungen im DNS gibt, sind die bestimmt nicht so in Time, wie die öffentlichen. Sicherer machts das ganze jedenfalls nicht..

[tuxlove]

Die entscheidende Lösung war in meinem Fall - neben einem Linux Install natuerlich, richtig - das
deinstallieren des "E/A-Treiber für Verbindungsschicht- Topologieerkennung"
+ ein anschliessendes neuinstallieren der verwendeten DFÜ Breitbandverbindung.

Das ganze per Telefonsupport (-: mit der berechtigten Frage des Users: Warum bezahle ich Geld für etwas das nicht funktioniert ? Ich hab empfohlen das mal so direkt an den Hersteller zu kommunizieren.Alter alter (-:

[TO_Webmaster]

Ich hatte das Ausgangsproblem auf einem Rechner (1511, 10586.36). Bei mir hat die Lösung aus dem MS-Forum (im Gerätemanager Netzwerkkarte löschen und neu booten) geholfen.

MfG TO_Webmaster

[Doodle]

Der PC wurde mit Win10 neu aufgesetzt und tagelang ging es gut. Aber nun geht der Sch§$%&& schon wieder los.
1. kam das:
2. kam das:
Das kann doch echt nicht wahr sein. Ein komplett neu aufgesetztes System und der Fehler ist immer noch da.
Gibt es eine Lösung?

Dieser Beitrag wurde von Doodle bearbeitet: 15. Januar 2016 - 17:58