ULi's späte Rache... Treiberleiche im Windows 10 1903 Upgrade nicht signiert

[syfsyn]

das Llstet erst mal nicht geladene treiber auf die in system 32 drvstore liegen
danach den command
pnputil -d oem(irgendwas)
das mache ich regelmäßig um alte nvidia treiber zu entfernen
Wichtig danach neustarten
das wird aber dein problem nicht lösen es liegt an deiner raptor Hdds die mal das raid hatte
Erst danach kannst den uli treiber entfernen
das es mal zu nvidia forceware gehörte legt nahe das mal ein nforce brett hattest.
Es muss sich dabei um ein software raid handeln.

 

[Boemi]

bootrec rebuild mbr

hatte ich schon über die Reparatur-Console versucht oder wie sich das Teil schimpft meine ich

Aber es wird an der Platte und dem mbr liegen und am Raid damals

Ergänzung (26. Mai 2019)

es könnte reichen wenn die mbr neu erstellt wird

Hab mit dem MiniTool mal Rebuild MBR gemacht - der Raid-Treiber is noch drin...

 

[Pitt_G.]

@Boemi das wird ein Pseudo RAID sein wie viele andere auch, ich kenn den Uli SATA Treiber so, dass er sich durch den Microsoft Standard IDE Treiber ersetzen lässt, einfach mal im Geräte Manager den Uli Treiber damit ersetzen, AHCI macht der nicht aber er spricht SATA ,
das mit dem Inaccessible kommt meist wenn von IDE auf AHCI umgestellt wird oder umgekehrt, sprich im BIOS gucken, wie der Port eingerichtet ist sollte erstmal auf Sata/IDE stehen

 

[Boemi]

Build 1903 läuft übrigens wieder ohne Testmodus

Lösung:

BCDEDIT -Set LoadOptions DISABLE_INTEGRITY_CHECKS
BCDEDIT -Set TESTSIGNING ON

Im Gerätemanager unter Aktion Legacyhardware hinzufügen (alle ULi und JMicron Controller die das System noch in petto hatte installiert, auch wenn da dann stand, dass das Gerät nicht gestartet werden konnten, wie auch, ist ja gar nicht mehr vorhanden), dann

Reboot, dann

BCDEDIT -Set LoadOptions ENABLE_INTEGRITY_CHECKS
BCDEDIT -Set TESTSIGNING OFF

Reboot und gut.

P.S.
Sieht aus, als hätte der Migrant nochmal Asyl bekommen

P.P.S.
Interessanterweise war in Windows.old/stystem32/drivers keine ulipnp.sys zu finden, hat sich also die Installationsroutine wohl irgendwo aus dem DriverStore gezogen, warum wusste sie wohl...

 

[Pitt_G.]

@Wadenbeisser das Dual Vista hat mich mal geärgert bei zwei Inplace Upgrades, die letzten gingen aber ohne dass ich mit einer Windows 8 DVD was reparieren musste , der Witz war, der erste Start ging jeweils, System runtergefahren , ups was ist jetzt los, war eine alte W7 HP Clean Installation, Multicore Themen gibt's glaub nur bei aktivem CnQ, aber das wurde im BIOS entfernt und ist nur mit XP verfügbar,
MS hatte mal einfach eine der zahlreichen Partitionen gelöscht

 

[Boemi]

einfach mal im Geräte Manager den Uli Treiber damit ersetzen, AHCI macht der nicht aber er spricht SATA

Im Geräte-Manager war ja seit Jahren kein ULi-Controller mehr...

Inaccessible kommt meist wenn von IDE auf AHCI umgestellt wird oder umgekehrt

lag hier definitiv daran, dass der ulipnp.sys von mir testweise deaktiviert/ gelöscht wurde, weil sich Win10 ja vorher über die fehlende Sig beschwerte

 

[Pitt_G.]

@Boemi , also irgendwo hängt der doch drin, Storage Spaces ?
Normal reicht es doch aus die Geräte im Device Manager nach Verbindung sich hierarchisch anzeigen zu lassen und gucken wo die HDD/Ssd dranhängt
Oder da Pseudo RAID wurde damals nicht richtig aufgelöst

 

[Boemi]

Geräte im Device Manager nach Verbindung sich hierarchisch anzeigen

Die Platten hängen alle am Intel-Chipset: ACPI>Stammkomplex PCI-E>Intel Chipset>Platten

Das System meint ihn wohl zu brauchen, weil es früher mal uli-raids gab (s.o.) - denk ich mal.

 

[Pitt_G.]

@Boemi, guck mal in die Speicherplätze in der Systemsteuerung rein

 

[Boemi]

guck mal in die Speicherplätze in der Systemsteuerung rein

da ist nix, habe aber mal im Geräte-Manager unter Laufwerke/ Eigentschaften/ Treiber geschaut, da steht Microsoft als Anbieter, aber unter Treiberdetails finde ich dann:

Treiberdateien:

disk.sys (signiert)
EhStorClass.sys (signiert)
partmgr.sys (signiert)
ulipnp.sys (hier nicht signiert)

Seit ich über Legacyhardware installieren, den ULI SATA/RAID Controller installiert habe, habe ich dort unter

Treiberdateien:
m5288.sys (signiert)
ULiPnp.sys (signiert)

und Windows schimpft nicht mehr, weil für die ulipnp.sys findet er ja dann dort die Signatur offensichtlich.

Deinstalliere ich den ULI SATA/RAID Controller, bleibt die ulipnp.sys unter den Treiberdateien für die Laufwerke stehen und er schimpft wieder, dass die Signatur nicht überprüft werden konnte. Wie bekomme ich die ulipnp.sys aus den Treiberdateien für die Laufwerke raus? Deinstallieren der Laufwerke bringt erstmal nix.

 

[Terrier]

ULI SATA/RAID Controller

Muss man sowas nicht im Bios deaktivieren oder aktivieren wenn man das braucht ?
Dein Bios und deine Controller lerne ich nicht.
Sieht auch bestimmt nicht so aus wie hier.
https://www.thomas-krenn.com/de/wiki/BIOS_Einstellungen

 

[Schildkröte09]

Suche doch mal in der Registrierdatenbank (regedit) nach "ULiPnp.sys " und lösche alle Schlüssel. Aber natürlich auf eigene Gefahr und Risiko. Eine Regedit Sicherung sollte man vorher eh anlegen.

Viele Grüße

 

[Boemi]

Muss man sowas nicht im Bios deaktivieren oder aktivieren wen man das braucht ?

Du kannst im Geräte-Manager Treiber für beliebige Hardware installieren. Das ist hier ein workaround, weil ich so ne Windows ne Signatur zu dem Treiber liefere. Auch wenn der Controller ja längst nicht mehr existiert.

Dein Bios und deine Controller lerne ich nicht.

nicht schlimm

 

[Terrier]

Solange der Controller irgendwie aktiv ist wirst du den auch nicht löschen oder deinstallieren können und wenn dann ist er beim nächsten Start wieder da.
Und wenn der ULI Controller gar nicht mehr auf dem Board ist, dann ist dein Windows kaputt.

 

[Boemi]

Solange der Controller irgendwie aktiv ist wirst du den auch nicht löschen oder deinstallieren können und wenn dann ist er beim nächsten Start wieder da.
Und wenn der ULI Controller gar nicht mehr auf dem Board ist, dann ist dein Windows kaputt.

Du hast das Problem nicht verstanden.

 

[Terrier]

Doch, Post 2, und 5 und noch einige andere Beiträge..
Post 3

bekomm's schon noch gefixt.

kannst du doch vergessen!

Wird Zeit für Post 14

 

[Boemi]

Ursache für das Problem war, dass der ulipnp unter UpperFilters in

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e967-e325-11ce-bfc1-08002be10318}

eingetragen war.

Ohne das Raid der ULi-Southbridge ist es nicht mehr nötig die Daten vor dem disk.sys noch durch den ulipnp.sys zu jagen. Unter UpperFilters steht jetzt nur noch partmgr.sys. Der ulipnp.sys wird jetz laut bootlog auch nicht mehr geladen.

Man lernt durch solche Probleme halt immer auch wieder etwas. Bspw. was es mit den Upper- und Lowerfilters bei Treibern auf sich hat.

 

[Schildkröte09]

Ursache für das Problem war, dass der ulipnp unter UpperFilters in

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e967-e325-11ce-bfc1-08002be10318}

eingetragen war.

Und, hast den Schlüssel aus der Registry gelöscht, oder? Wie schon in # 52 vorgeschlagen ...

 

[Boemi]

Und, hast den Schlüssel aus der Registry gelöscht, oder? Wie schon in # 52 vorgeschlagen ...

Den Schlüssel nicht, unter UpperFilters stand neben ulipnp noch partmgr drin, den ganzen Schlüssel zu löschen erschien mir unklug, zumal der Schlüssel ja nötig ist. Also habe ich nur einen der beiden Einträge unter UpperFilters in diesem Schlüssel entfernt. Laut .inf-Datei des Uli-Treibers trägt sich der ulipnp dort nämlich unter UpperFilters ein, nur offenbar löscht er sich bei deinstallation dort nicht...