(geloest) Win 7 will seinen Product-Schluessel nicht mehr

Michael Siam

Active member
Themenstarter
Registriert
10 März 2013
Beiträge
676
Seit gestern habe ich folgendes Problem:
Ich habeein Windows 7 Ultimate, voellig legal mit gueltigen Product-Schluessel.
Das System besitze ich schon ueber 3 Jahre.
Habe es regulaer gekauft
Richtig nutzen tue ich es aber erst seit ca. 10 Monaten.
Gestern Abend bekomme ich ne Meldung, das mein Windows nicht legitim waere.
Wie kann das sein, wenn ich doch bei der Installation meinen dazugehoerigen Product-Schluessel angegeben habe und dieser auch akzeptiert wurde.


Ich wollte schon Microsoft anrufen, aber da ich nur ein Handy habe fuer Telefonie, komme ich nicht zu denen durch.
Das Internet laeuft seit Oktober ueber Tethering (D1 Dataflat)
Hat jemand eine Idee, warum das auf einmal so ist.


Laufen tut das System noch und die Meldungen fuer vorhandene Updates kommen auch.
 
Zuletzt bearbeitet:
Die WAT-Prüfung (vormals WGA) wird von MS als "Wichtige Update" angeboten und als “KB971033" installiert. Dieses "telefoniert" etwa alle 90 Tage "nach Hause"

Und woher stammt jetzt das Wissen von den ungefähr 90 Tagen? Der KB Artikel bezieht sich auf eine Prüfung des Zustandes, wenn eben jenes Update installiert wird.

Wenn Dateien defekt sind, die nicht wiederhergestellt werden können und diese Dateien die Aktivierung beeinflussen, dann passiert genau das, was der TE gehabt hat. Das System gibt eine Meldung aus und der User wird mit weiteren Informationen versorgt.

MS legt da sicherlich nicht alles offen, aber schon eine ganze Menge. Deswegen finde ich es ziemlich spannend, wenn manch einer hier genau weiß, was wann wo wie oft nach Hause telefoniert. ;-)
 
@MichaelSiam:
Du kannst deine Frage auch im Forum answers.microsoft.com stellen. Dort sind MS-Experten unterwegs.

Im Microsoft-Supportforum habe ich gestern eine Frage gehabt zu meinen Problem.

Er fragte mich, ob ich ein Programm namens KIES fuer Samsung Handys installiert haette.

Ich hatte dieses KIES tatsaechlich auf meinen System und zwar Ende Maerz fuer ein paar Tage.
Ich habe von einen Samsung Note 3 eine Datensicherung gemacht, da dieses verkauft werden sollte.

Dieses KIES habe ich denn wieder deinstalliert.
Kann da irgendein Zusammenhang gewesen sein?
 
Nun, die Frage wird nicht von ungefähr kommen.

Was vielleicht auch klappen könnte: Eine Systemwiederherstellung auf den Stand, als es noch lief.
 
Das hatte ich zuerst versucht.
Da war denn dieses geloeschte KIES wieder da u.v.m.
Das eigentliche Problem loeste sich damit nicht.
Die Neu-Installation hat das Problem denn geloest, Windows 7 laeuft wieder wie es soll.
Es laeuft sogar schneller als vorher.
 
Die einzigen Programme, die da nicht mehr laufen sind 16Bit basierende Oldies, die aber grundsätzlich in einer Windows2000/WindowsXP VM besser aufgehoben sind, da sie unter Windows 7 generell gerne rumzicken, der Rest sollte und wird unter einem x64 System genauso laufen wie bisher ;)
Einspruch! Es gibt durchaus Programme, bei denen es sich um 32bit-Anwendungen handelt und die unter 32bit-Betriebssystemen hervorragend laufen, unter 64ern aber nicht.
Ich kämpfe z.B. aktuell wieder mit "TwinCAT" von Beckhoff in der Kombination mit C++-Modulen aus Matlab. Bisher war das unter 64Bit-Systemen überhaupt nicht lauffähig. Laut Beckhoff ist es inzwischen 64Bit-fähig, aber das ganze wirklich zum Laufen zu bekommen, ist ein absoluter Krampf und bisher habe ich keine lauffähige Version. Unter 32Bit ist das: installieren, starten, läuft. Unter 64Bit "spielt" man dann mit zusätzlichen Umgebungsvariablen rum, muss Windows in den "Test-Signing"-Modus bringen, um die Prüfung von Signaturen abzuschalten und generiert sich dann eigene Zertifikate, die man versucht, wieder als vertrauenswürdig einzustufen. Usw usf. Alle Versuche hier im Institut, das ganze am Ende wirklich lauffähig hinzubekommen, sind bisher gescheitert. Ich hab es schon mal kurz lauffähig gehabt, dann hat es aber doch wieder undefinierbare Fehlermeldungen gehagelt. So läuft bisher alles auf 32Bit, was TwinCAT (insbesondere in der Kombination mit Matlab) ausführen soll. Aktuell habe ich hier aber einen Rechner mit IvyBridge Core-i7 und 16GB RAM, auf dem das alles laufen soll - da macht 32bit keinen Sinn. Also probiere ich mal wieder mein Glück mit der 64Bit-Variante von Windows.

Aber wie gesagt, es liegt nicht immer an uralter 16Bit-Software, auch aktuelle Software (Matlab 2013B [2013] + TwinCAT 3.1.4014 [2014]) kann unter 64bit Probleme machen.
 
auch aktuelle Software (Matlab 2013B [2013] + TwinCAT 3.1.4014 [2014]) kann unter 64bit Probleme machen.
Was man ja wohl nur als Armutszeugnis bezeichnen kann. Wer möchte sich auf einigermaßen aktueller Hardware denn heute noch auf ca. 3,5 GB RAM beschränken?
 
Unter 64Bit "spielt" man dann mit zusätzlichen Umgebungsvariablen rum, muss Windows in den "Test-Signing"-Modus bringen, um die Prüfung von Signaturen abzuschalten und generiert sich dann eigene Zertifikate, die man versucht, wieder als vertrauenswürdig einzustufen.

Wenn man Windows mit eigenen Zertifikaten im "Test-Signing" Modus betreiben muss bedeutet das, dass der Hersteller geschlampt hat und sich hardwarenahe Komponenten nicht hat ordentlich von M$ zertifizieren lassen. (Eigentlich ein nettes Geschäftsmodell von M$, jeder Treiberhersteller muss nochmal bei M$ Zoll zahlen...). Also nicht unbedingt ein Problem von win64 direkt, eher ein Nebenprodukt des Windows-Geschäftsmodelles.
 
Die Module, die da erstellt werden, werden aber lokal auf dem Rechner erstellt, nicht beim Hersteller. Daher nicht nur der Test-Signing-Modus, sondern gleich noch ein selbst generiertes Zertifikat dazu. Trotzdem weiß ich nicht, ob das unbedingt nötig ist, denn meiner Meinung nach haben die Komponenten wenig mit hardwarenahen Treibern zu tun, die da erstellt werden.
 
Wenn man Windows mit eigenen Zertifikaten im "Test-Signing" Modus betreiben muss bedeutet das, dass der Hersteller geschlampt hat und sich hardwarenahe Komponenten nicht hat ordentlich von M$ zertifizieren lassen. (Eigentlich ein nettes Geschäftsmodell von M$, jeder Treiberhersteller muss nochmal bei M$ Zoll zahlen...). Also nicht unbedingt ein Problem von win64 direkt, eher ein Nebenprodukt des Windows-Geschäftsmodelles.

Das ist mal wieder so eine unsägliche Sache, die sich immer weiter in den Köpfen hält. Nein, Microsoft muss die Treiber nicht zertifizieren und niemand muss an Microsoft da etwas zahlen. Das ist reiner Unsinn.

Treiber bei 64-bit Windows müssen SIGNIERT sein. Eine qualifizierte Signatur dafür kommt nicht von Microsoft, sondern von einer der bekannten Zertifizierungsstellen - gerne also z.B. von Verisign aka Symantec. Und solche signierten Treiber nimmt das System an, den Rest eben nicht. Das ist grundsätzlich erst einmal ein sinnvolles Sicherheitsfeature, damit eben nicht jeder Malware-Bastler irgendwelche Treiber ins System schummeln kann.

Damit Microsoft die Treiber über Windows Update bereitstellt, müssen sie eine WHQL Zertifizierung bestehen, da sie dann halt direkt von Microsoft selber an den Kunden ausgeliefert werden. Und dies kostet dann Geld bei Microsoft selber, weil da nun einmal auch Microsoft selber Zeit investiert, um die Treiber zu prüfen - wie auch immer im Detail solch eine Prüfung dann aussieht.
 
  • ok1.de
  • IT Refresh - IT Teile & mehr
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben