Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 48 reacties

Een voormalig Microsoft-medewerker heeft een script gemaakt dat het probleem zou moeten oplossen van pc's die eindeloos blijven rebooten na installatie van Service Pack 3 voor XP.

Designed for XP logoDe problemen met SP3 zouden vooral voorkomen bij HP-pc's die met een AMD-processor zijn uitgerust. Het meegeleverde XP-image van de HP-desktops zou destijds gemaakt zijn op een systeem met een Intel-processor, terwijl de machines draaien op een AMD-cpu. Microsoft waarschuwt fabrikanten al sinds 2004 om dit niet meer te doen, nadat bij de uitrol van SP2 soortgelijke problemen aan het licht kwamen. Door de fout in het image zou Windows na installatie van SP3 Intelppm.sys, een driver voor Intel-chips, proberen in te laden. Doordat deze hardware niet beschikbaar is kan XP niet meer geboot worden.

Jesper Johansson, voormalig manager security policy bij Microsoft en thans werkzaam bij Amazon.com, heeft een eenvoudig Visual Basic-script gemaakt waarmee deze fouten in het register gerepareerd kunnen worden. In veel gevallen zouden eindeloos rebootende systemen na de ingreep weer keurig opstarten.

De problemen met SP3 zouden overigens niet alleen op pc's met een AMD-processor voorkomen. Volgens Johansson zouden ook systemen met bepaalde Asus-moederborden of verouderde videodrivers voor Ati-videokaarten getroffen kunnen worden. Ook voor deze configuraties biedt de blog van Johansson mogelijke oplossingen. Microsoft heeft nog niet gereageerd op het werk van zijn voormalig werknemer, maar de softwarefabrikant moet meestal niets hebben van niet-officiële patches en geeft ook geen enkele ondersteuning aan dergelijke oplossingen.

Moderatie-faq Wijzig weergave

Reacties (48)

Er is overigens nóg een manier om de intel_ppm uit te schakelen door in de Recovery Console met SC te werken.

disable intelppm


Als je vóór je SP3 installatie wil kijken of die service aanwezig is (want deze wordt niet geinstalleerd door SP3 maar alleen geactiveerd als die aanwezig is terwijl die eigenlijk niet hoort aanwezig te zijn):

C:\WINDOWS>sc query intelppm

SERVICE_NAME: intelppm
TYPE : 1 KERNEL_DRIVER
STATE : 4 RUNNING
(STOPPABLE,NOT_PAUSABLE,IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0

Uitzetten kan dan met

sc config intelppm start= disabled
(ja die spatie hoort daar te staan).
Het is natuurlijk best mogelijk dat deze scripts gewoon dat uitvoeren wat er vermeld staat als oplossing in de MS KB. Als ik het goed heb is een kleine registryhack al voldoende om het probleem op te lossen.edit: http://support.microsoft.com/kb/888372
Imho kan je dan moeilijk van een "patch" spreken, en heeft MS dit noch goed- noch af te keuren! Tenslotte is het maar een vb-scriptje dat wat registry spul voor je oplost...

edit2: typos

[Reactie gewijzigd door the_stickie op 18 mei 2008 18:19]

Imho kan je dan moeilijk van een "patch" spreken, en heeft MS dit noch goed- noch af te keuren! Tenslotte is het maar een vb-scriptje dat wat registry spul voor je oplost
Het probleem wat MS hiermee heeft is dat je nooit weet of dat ook daadwerkelijk het enige is wat deze onofficiele fix doet. Voor hetzelfde geld word er, naast de fix, ook meteen even een backdoor, trojan, virus, etc meegeinstalleerd waardoor je PC opeens in een botnet kan worden opgenomen danwel anderszinds misbruikt.

Daarnaast, hoe kan MS nu support leveren op een fix die door anderen is geschreven en waar ze zelf de source niet van hebben?

Deze Johanssen is dan overigens weer wel een betrouwbaar persoon, dus in dit specifieke geval zal het wel OK zijn. Maar ik kan me best voorstellen dat MS dit soort dingen liever niet ziet, om bovengenoemde redenen.
Zoals the_stickie ook al schreef, het is puur een "Visual Basic-script". Hierbij is de broncode in te zien, dus ook Microsoft kan zien wat de ex-medewerker doet met de computers waar dit script op gedraait wordt.

Er zijn twee scenario's denkbaar. 1) Microsoft gebruikt deze methode als 'officiele' patch (of maakt z'n eigen patch adhv deze 'non official') of 2) Microsoft bedenkt zelf iets totaals.

Ik gok dat ze voor optie 1 gaan, gezien het een probleem is wat sowieso al veroorzaakt wordt door 3rd party's (image maken op een Intel systeem en uitrollen op een AMD, hoe slim ben je dan als hardwarebouwer?), of drivers die vaak niet goed geschreven zijn. Ik vraag me dan wel af of in dit geval de ATi drivers een 'driver signing' hebben (als dit het geval is, dan vraag ik me direct af 'waarom' de driver signing ook alweer gemaakt was? Juist voor stabiliteit en garanties toch? Dan geeft MS deze fout uit!). Het is eigenlijk een probleem wat 'anderen' veroorzaken door niet correct te handelen (gok ik zo). Waarom zou Microsoft dan geen patch van een ex-medewerker mogen accepteren?

Als dit onder linux zou gebeuren dan zullen er wat mensen zeggen 'eigen schuld, gebruik dan maar software die compatible met elkaar is', maar in het geval van Windows is het meteen de schuld van Microsoft? Rare redenering hoor. Ik vind, zoals het nieuwsbericht hier schetst, het probleem bij HP en ATi liggen, en niet bij Microsoft.

Ik heb sowieso een hekel aan 'standaard' images van een leverancier (en ik heb er genoeg van HP gezien, in m'n achterhoofd houdend dat we ongeveer 70 desktops, 20 servers en 20 laptops hebben van HP, allemaal met een 'eigen' image).

[Reactie gewijzigd door KingOfDos op 19 mei 2008 07:57]

er zijn zat vbs'jes te vinden op het internet voor allerlei administrative taken op windows pc's. Ik snap niet wat het verschil is tussen dit scriptje en alle andere "handige scriptjes".
Natuurlijk houdt het progwerk van derden altijd een veiligheidsrisico in, maar dat is in dit geval goed te controleren: het gaat immers om een gewoon *.vbs bestand.
Omdat men ervan uit gaat dat hetgeen wat MS distributeerd zowieso niet kwaadwillend is terwijl je bij Jesper Johansson of wie dan ook die handige scriptjes maakt er maar vanuit moet gaan dat dit daadwerkelijk safe is. Iets wat wildhagen dan ook aangeeft. Tevens kun je er bij handige administratieve scriptjes er wel vanuit gaan dat de desbetreffende admin die deze gaat gebruiken enigszins weet wat het risico is of zelfs de scripts controleerd alvorens hij ermee aan de slag gaat, iets wat een gewone eindgebruiker niet zal doen.
Ik vind het zelf ietwat slordig dat als MS dit weet, niet dit even mee verwerkt in de SP3. Het is een minimaal iets lijkt me om ff een scirptje een check te laten doen om welke mobo/cpu combinatie het gaat en dit te vergelijken tov wat HP aan systemen geleverd heeft.
@n4m3l355:
Het maakt niet uit of gewone eindgebruikers dit wel of niet zelf zullen controleren.
Het punt is dat 't makkelijk in te zien is, dus door anderen zal dat ook zeeeeer zeker gebeuren. Die Jesper wil heus niet in een kwaad daglicht komen te staan, dus zal er heus niet bewust malware inzitten. Da's nu 't voordeel van code die je in kan zien!
Eindgebruikers HOEVEN helemaal niet de code in te kijken - als je 't in KUNT kijken, weet je eigenlijk al bijna 100% zeker dat er nooit bewuste malware in zal zitten. Simpelweg omdat sommige geavanceerde gebruikers toch in de code zullen (of i.i.g. kùnnen) kijken, dus gesnapt wordt je uiteindelijk altijd. Met Closed Source is 't ALTIJD maar afwachten welke troep er in zit.
Voor hetzelfde geld is deze fix gewoon open-source het is slechts een "scriptje" dus betrouwbaar hoeft die vent niet eens te zijn.

Verder wel eeerg zwak dat dit al een patch is voor het probleem en dit eigenlijk in Windows zelf gebakken zou moeten zitten.
Verder wel eeerg zwak dat dit al een patch is voor het probleem en dit eigenlijk in Windows zelf gebakken zou moeten zitten.
Dus een Servicepack installatie moet van jou ook op bewuste misconfiguraties van derden lopen controleren? :)
ja, in goede software zit altijd foutcontrole en -correctie
dus als ik ondanks het feit dat de fabrikant zegt dat ik geen katten in de magnetron doe, ik er toch eentje in stop.. zou de software van de magnetron eigenlijk dit zelf moeten detecteren en moeten stoppen?

HP had dit gewoon al tijdje terug moeten fixen.
wie zegt dat ze dut niet hebben gedaan? ik ken genoeg mensen die de HP update manager weg klikken en dan roepen: volgens mij heb ik een spamvirushacker want ik krijg steeds meldingen als ik op internet ga...
Verwonderd mij niet van HP.

ouwe brakke brol hergebruiken en niet controleren of er geen wijzigingen zijn.

genoeg NC6000 zien "kapot gaan" omdat de HD packing gebleven was maar niet compatibel met de nieuwe HD's.

Staat nochtans op elke HD do not cover this hole.
wat doet HP , sticker over cover en gat dan merkt geen kat het nog.

dit is geen fout van MS, maar van HP.
Niet compatibele dingen gebruiken!
Daarnaast, hoe kan MS nu support leveren op een fix die door anderen is geschreven en waar ze zelf de source niet van hebben?
Wat nou geen source hebben?

rechtermuisklik -> open met notepad

Het gaat hier om een vbs file... plain tekst....
Ik heb het script gecontroleerd, en het doet precies wat je zegt: als er een AMD processor is dan wordt een functie aangeroepen die de waarde uit jouw link op 4 zet als deze nog geen 4 is. Als je geen AMD proc hebt doet hij helemaal niks.
Het probleem is dus dat HP een key in het register zet om intelppm.sys te laden.
Terwijl die driver in eerste instantie niet aanwezig is in die AMD image.

SP3 ziet dat die driver geladen moet worden en installeert de nieuwe driver.
De nieuwe intelppm.sys driver wordt geladen en het AMD systeem crasht.

Puur een fout van HP heeft niks met SP3 te maken.
SP3 gaat er terecht van uit dat drivers die geladen moeten worden ook aanwezig zijn.

[Reactie gewijzigd door Soldaatje op 18 mei 2008 17:25]

In zoverre: die driver is er wel, omdat er een generieke image is gebruikt.
Maar de hardware is er niet...
Dan moet de driver niet geladen worden. Zo gaat het in elk ander besturingssysteem. Als de driver aangeroepen wordt, controleert deze zelf of de hardware aanwezig is, zoniet, dan gebeurt er niets.

Windows is ook het enige besturingssysteem dat ik ken wat je niet altijd zomaar kan overzetten naar andere hardware, omdat blijkbaar bij de installatie bepaald wordt wat er wordt geladen, en niet tijdens het booten van de kernel.
Geen enkel ander (grafisch) besturingssysteem kun je zomaar werkend overzetten naar andere hardware, als de benodigde drivers daarvoor ontbreken, dat is niet alleen een probleem van Windows.
Geen probleem met Linux, geen probleem met OSX (als je 't goed doet kun je zelfs een systeem op zowel intel als ppc macs booten), geen probleem met Solaris, etc. etc.
Uhmm, ik ken anders zat disto's van linux waarbij je dat ook niet hoeft te proberen hoor.
Linux = Linux ongeacht de distro en een server die de stock kernel draait kan zonder problemen binnen de architectuur (i386/amd64/sparc/etc) naar andere hardware worden overgezet. Een 64 bits systeem overzetten naar hardware dat alleen 32bits extensies heeft, gaat natuurlijk niet lukken.

Daarnaast kan een Linux desktop systeem ook aardig makkelijk worden overgezet. Over het algemeen zal een videokaart met een ander merk GPU problemen kunnen geven, maar dit is echter het makkelijkst op te lossen door voor de migratie de video driver er uit te slopen door de xorg.conf aan te passen en na de migratie de nieuwe driver te installeren. Alle overige drivers worden automatisch door de kernel geladen.

En draai je je eigen gebakken kernel, is het een kwestie van een nieuwe kernel bakken met voor het nieuwe platform specifieke drivers. Een nieuwe chipset, SCSI en NIC driver is over het algemeen voldoende. En zeker onder UNIX er op letten dat je fstab voor de migratie aanpast.

Dus ja, het is alleen Windows dat totaal niet overgezet kan worden naar een ander platform. Met *nix is het vrij simpel te doen met als voordeel dat een *nix serverinstallatie jaren of wel tientallen jaren mee kan gaan.

Ik hoop dus van harte (voor Microsoft) dat Windows ook eindelijk eens modulair wordt, ipv dat MS om de zoveel jaar weer iets 'nieuws' uitbrengt.
Windows in de VGA mode kan meestal ( mogelijk niet altijd, maar ben iknog niet tegengekomen) probleemloos overgezet worden. Ik weet dus niet welk verschil jij denkt te zien?
Weet ik wel, maar het was maar om verder te verduidelijken.

Hier gaat MS toch wel beetje de mist in.
Raar dat Microsoft dit zelf niet heeft opgelost. Sowieso vind ik de QA een beetje dubieus met SP3. Na de installatie van SP3 kon ik mijn computer niet meer booten, ik kreeg maar telkens een blauw scherm. Dit lag uiteindelijk aan het moederbord wat ik heb. Op zich geen ramp, ware het niet dat tijdens de beta tests al problemen waren geconstateerd icm dit type moederbord, en die zijn dus ook nooit opgelost... Na lang zoeken gelukkig toch een oplossing gevonden, maar het blijft wel een vreemde kwestie
Raar dat Microsoft dit zelf niet heeft opgelost
Daar zijn ze heus wel mee bezig hoor. Zoiets kost nu eenmaal een hoop tijd, want er moeten een heleboel (regressie-)tests gedaan worden om ervoor te zorgen dat de fix weer geen andere problemen veroorzaakt.

Daarnaast is er niet één duidelijke oorzaak aan te wijzen, want het speelt niet alleen op HP-systemen met AMD-processoren, want er zijn ook meldingen binnengekomen van mensen met Intel-processoren en andere merken PC's die het probleem ook hebben. Dat maakt het ontwikkelen van een fix die in alle situaties goed werkt ook niet bepaald makkelijk.

[Reactie gewijzigd door wildhagen op 18 mei 2008 17:35]

Er is imho/afaik geen enkele indicatie dat MS werkt aan een patch voor dit probleem. Het probleem vloeit immers voort uit een niet-ondersteunde actie: het deployen van images die gemaakt zijn op andere hardware (lees ff de readme van sysprep: daar staat heel duidelijk dat het niet ondersteund wordt).
Bovendien staat de fix al in de kb.
De andere "issues" waarover oa in de bron van dit artikel gesproken wordt, zijn namelijk te wijten aan bijvooreeld non-compliant biosversies (die acpi (nog steeds) niet juist ondersteunen), drivers uit de tijd dat de dieren nog spraken en beheerders die elk goed advies mbt sysprep en het gebruik van ghost en newsid in de wind slaan.

het is voor niemand leuk dat er problemen zijn, maar daarom hoeft MS het gepruts van anderen niet op te lossen :p
Er is imho/afaik geen enkele indicatie dat MS werkt aan een patch voor dit probleem
Die is er wel degelijk, zie o.a. dit nieuwsbericht, of doorzoek het forum van Microsoft (bijvoorbeeld in deze thread), waar ook al herhaaldelijk is gezegd dat Microsoft met het probleem bezig is.
Microsoft, meanwhile, acknowledged Thursday that it's working on a hotfix of its own.
en uit hetzelfde bericht:
"Microsoft is also developing a prerequisite fix that must be downloaded before SP3 will automatically install prior to its proactive distribution of SP3," HP statement added.

The Microsoft update that HP referenced is in the works, a Microsoft spokeswoman confirmed Thursday. "Microsoft is developing a hotfix for this issue, and will be available after it has been rigorously tested and meets our quality bar for release," she said in an e-mail Thursday afternoon.

[Reactie gewijzigd door wildhagen op 18 mei 2008 18:41]

@wildhagen:
Ze zijn er dus wel mee bezig... Maar ze piepen over een 'quality bar', terwijl er maar één cijfertje (die aangeeft welke CPU je hebt) hoeft te worden veranderd. Wat moet je daar eigenlijk nog verder aan testen...
Verder is 't gewoon vreemd dat Windows tijdens 't booten niet eenvoudig kan zien welke CPU er in zit... Dat kon DOS 15 jaren geleden al. Dus dat in 't image ingebakken zit dat 't een AMD CPU is of niet, doet er eigenlijk niet toe. Ik denk dat 't nog geen microseconde duurt om Windows uit te laten lezen of er nu AMD of Intel (of VIA of welke CPU dan ook) in zit.

[Reactie gewijzigd door kimborntobewild op 18 mei 2008 23:02]

Je wordt gedwongen om Certified drivers te gebruiken voor vista en kan bijna onmogelijk iets anders installeren.
(microsoft is wel degelijk bezig met zulke zaken dus)

Waarom is er geen check die kijkt of je CPU wel de juiste drivers ingeladen krijgt?
Dit is net zoiets als ik installeer een nieuwe videokaart maar om het werkend te krijgen moet ik windows opnieuw installeren omdat het anders onjuiste drivers inlaad en over zijn nek gaat.

Zulk soort detecties worden voor de raarste dingen bedacht onder het mom van veiligheid.
Waarom moet het dan zo moeilijk met zoiets simpel als CPU hardware detectie?

Dit is duidelijk een zaak van, microsoft is niet overtuiged dat dit het probleem is een verder gaat kijken dan een of ander tijdelijke oplossing voor een bepaalde hardware type.
Waarom kan een kernel niet gewoon (al dan niet silently, maar in ieder geval gracefully) verder gaan als een foute driver geladen wordt?

Als ik op mijn (Centrino) laptop de AMD speedstepping modules inlaad (powernow voor k7's), dan begint het ding echt niet spontaan te rebooten. Da's van Intel naar AMD ipv van AMD naar Intel natuurlijk, maar het verschil is fundamenteel en niet driverspecifiek...
Omdat de driver niet "fout" is, of beter gezegd, de fout zit in de driver zelf. Die heeft geen sanity check om te kijken of hij wel zinvol is voor het geval de installatiemechanismen het verprutst hebben (zoals in dit geval HP), hij rekent er gewoon op dat hij wel nuttig zal zijn als hij ingeladen wordt.

Dat kan de kernel van buitenaf niet zien, die laadt gewoon de driver en die moet de zaken dan verder goed opknappen, anders is een bluescreen onvermijdelijk. Drivers hebben van zichzelf geen informatie voor welke hardware ze nuttig zijn; het is aan de installatie (en voor Plug and Play hardware aan de bus driver) om dat te bepalen.
Ben ik de enige die problemen heeft met de drivers van Logitech? Ik bedoel, ik had SP3 geïnstalleerd en ik kreeg een BSOD meteen na de installatie en de reden was een logitech driver.
Jammergenoeg hebben wij 2 weken geleden zelf een vbs scriptje geschreven om dit probleem op te lossen... k*t intelpps bug, we hadden het pas na een paar dagen door omdat we met een nieuw image aan het bouwen waren en bij het testen kwam deze bug naar voren.
Wat een stel prutsers daar bij HP. niet eens even de tijd genomen om een passend image samen te stellen. das vragen om problemen.

Van de andere kant, MS kan gemakkelijk checken wat voor CPU er in het systeem zit , voordat SP3 geinstalleerd wordt, en niet blind uitgaan van een register setting die toevallig aan staat..
Waarom niet? Als Windows op de normale manier geïnstalleerd zou zijn op het systeem, met de bijbehorende drivers, zou het probleem zich niet voordoen. Dat HP (zoals altijd) te laks is om zijn zaken goed voor elkaar te hebben, daar kan MS op zich niet veel aan doen, het is niet eens de verantwoordelijkheid van MS.
weet niet of meer mensen dit probleem ook hebben die SP3 die op een AMD systeem hebben geinstalleerd, maar als je de computer in stand-by wilt zetten blijft ie hangen. Dit had ik niet voor installatie van SP3
Ik Heb dat wel bij de AMD machine Bij de Intel heb ik dit niet.
De AMD heb ik nu voorzien van Ubuntu voor gewoon surfen op internet.

Mijn ervaringen met AMD zijn zo ie zo niet altijd even prettig. Nieuwe pc's/laptops die ik aanschaf hebben dus als eis dat er geen AMD in zit. Het moeten betrouwbare pc's zijn.
Opzich wel jammer AMD is veel goedkoper.
ehm thombias ik denk nu echt niet dat het probleem met bij uw amd chippie zal liggen, zij hebben MS toch niet verplicht om een slechte sp3 uit te brengen?
Ze hebben AMD ook niet verplicht slechte CPU's uit te brengen...
En SP3 is voor mijn machines een verbetering dus

Ik wil alleen maar zeggen dat de AMD pc met SP3 vaak gecrashed is en met de Intel PC's heb ik nog geen problemen gehad. Mijn ervaringen uberhaupt met AMD zijn niet positief. Wat voor OS en SP dan ook. Stabiliteit is nu eenmaal belangrijk voor mijn werkzaamheden.
nee Sundance , alles is keurig op de C:\ geinstalleerd ook de progamma's onder windows zijn in C:\PROGRAM FILES\ geinstalleerd .
Dus mischien een andere optie ?
Je zou ook je vraag in Forum - Windows Clients kunnen zetten in plaats van hier, want het heeft niks met het onderwerp van het artikel te maken.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True