Uppdatering 2014-12-05: Det tog många veckors harvande fram och tillbaka med Microsoft innan de till slut lyckades förstå och återskapa problemet (skulle jag återberätta alla turer om hur Microsofts tekniker inte kan följa en busenkel steg-för-steg instruktion, inte kan använda verktyg som MDT, inte vet vad ett språkpaket är eller hur det installeras, inte vet var de laddar ned sina egna programvaror osv, så skulle det bli en hel bloggpost i sig…). Men nu är alltså problemet bekräftat av Microsoft och eskalerat till ansvarigt produktteam, så förhoppningsvis dyker det inte upp i framtida patchar.
Jag har den senaste tiden spenderat en hel del tid hos en kund med att felsöka ett mycket irriterande problem. För ett par år sedan byggde jag åt denna kund en mycket komplex och avancerad deployment lösning baserad på MDT. Den är komplex för att kunden har många väldigt specifika krav och behöver kunna hantera en lång rad olika typer av scenarion. Under åren som gått har jag regelbundet uppdaterat, vidareutvecklat och byggt vidare på denna lösning, för att hantera nya funktioner och krav. Allting följer mycket noggranna processer med versionshantering, förändringshantering, dokumentation och testning innan någonting får släppas till produktion. En återkommande del i detta underhållsarbete är att uppdatera Windows imagen, så att den innehåller de senaste uppdateringarna från Microsoft.
Så långt allt väl, och allting har fungerat utmärkt. Fram till i somras då det åter igen var dags för mig att släppa en ny deployment version, som innehöll diverse nya programvaror, diverse ny konfiguration samt en ny uppdaterad Windows image. Först såg allting ut att gå bra. Men kundens testavdelning är extremt noggrann och professionell, och efter en hel del testning upptäckte en testare att en nyinstallerad dator, med den nya imagen, inte gick att starta. Installationen hade slutförts, datorn befann sig inne i Windows, testaren gick på lunch, kom tillbaka och startade om datorn. I det läget kunde inte längre Windows starta, utan allt som visades var en svart skärm och en muspekare. Ingen blåskärms-krasch eller liknande alltså, bara denna svarta skärm och ingenting mer.
Andra datorer som installerades visade inte upp samma problem, och först tänkte man inte så mycket mer på detta. Tiden gick, det blev semestrar osv. I produktion körde man vidare på den äldre imagen, och där var allt frid och fröjd. Men efter sommaren fortsatte testerna med den nya imagen (samt alla andra nyheter såsom nya programvaror och konfiguration, osv). Och nu började man se ”svartskärms-buggen” oftare.
Just för att det är en såpass komplex deployment lösning, bl.a. så använder man ca 15 olika språk, samt en uppsjö olika konfigurationer som man kan välja för en dator, så tog det tid att ringa in problemet. Ibland verkade det hända och ibland inte.
Efter tag stod det dock klart att problemet uppstod och kunde återskapas om följande var sant:
- Ett språk annat än US English (detta är det språk som imagen är byggd på) valdes. Samma problem med alla övriga 14 språk.
- Strömkabeln sitter i.
- Låt datorn stå påslagen en timme efter installation, starta om den. Voilá, en svart skärm.
Just att strömkabeln måste vara i kändes mycket märkligt, och ledde först misstankarna till strömsparfunktionerna i Windows. Vi har nämligen byggt helt egna energisparscheman som installeras under deployment. Men att testa att återställa dessa till Windows default hjälpte inte.
Så varför uppstår problemet bara när datorn varit påslagen en viss tid, och varför bara med strömkabel i, och aldrig på batteri? Och varför bara när ett språkpaket är installerat?
I det här scenariot används Windows 7, men inte Enterprise som tillsammans med Ultimate är de enda editions som kan ha flera språk installerade samtidigt. Det går dock, tvärtemot vad många tror, alldeles utmärkt att byta språk även i andra editions av Windows 7. Det bör helst göras i offline läge innan Windows setup-program körs, men går faktiskt att göra ”online” också, efter att Windows har installerats. Så följaktligen, kör man MDT använder man sig av steget ”Install updates offline” för att applicera ett språkpaket i Windows PE läget, så kommer setup-programmet sen gladeligen att installera detta språk.
Men vad som sen händer, som är lite mer hemligt, är att Windows kommer skapa en schemalagd aktivitet som körs en gång exakt 25 minuter efter att Windows startat första gången. Denna aktivitet kör filen %Windir%\System32\Lpremove.exe. Detta lilla jobb har som uppgift att rensa ut de sista resterna av orginalspråket som låg i imagen, om detta är något annat språk än det aktuella språkpaketet som är installerat.
Det vi upptäckte efter en hel del felsökande var att det var just detta lilla schemalagda jobb, som är konfigurerat att köras endast på AC power, som var boven. Så fort vi körde det jobbet (eller bara manuellt startade Lpremove.exe) och sen startade om datorn, så hamnade vi i svart-skärms-träsket.
Ok, så nu visste vi i alla fall vad det var som utlöste problemet, men varför det kunde ske kvarstod att utreda. Vi kunde snabbt konstatera att den deployment-version som användes i produktion inte hade problemet. Alltså låg problemet i någon av de förändringar som jag hade gjort i senaste uppdateringen, vilket alltså bl.a. innefattade en uppdaterad Windows image.
I det här läget vill man ju gärna börja misstänka drivrutiner eller någon 3:e-partsprogramvara. Men efter en hel del testande kunde jag konstatera att problemet uppstår på vilken hårdvara som helst, och även i virtuella maskiner, utan att några som helst drivrutiner installeras, eller några programvaror eller någon konfiguration eller någonting. Alltså bara en ”ren” installation av Windows och ett språkpaket.
Slutsatsen blev alltså att det måste vara en uppdatering i imagen som var den skyldige. Jag testade med den äldre image som användes i produktion, och även med en image helt utan uppdateringar, och då försvann genast problemet. Så därmed började det mödosamma arbetet med att hitta exakt vilken eller vilka uppdateringar som var problemet.
Efter mycket tidskrävande sökande har jag till slut funnit att det är inte mindre än FYRA olika uppdateringar, som var och en orsakar detta problem. Dessa är:
Alla dessa uppdateringar, varav tre är Security Updates, är släppta mellan maj och september i år. Är detta ännu ett tecken på att kvaliteten på Microsofts uppdateringar har nått nya bottennivåer (ni minns säkert uppdateringarna i somras som drogs tillbaka)? Har man helt gett upp all form av test- och kvalitetsarbete på Microsoft?
Så lösningen nu är att exkludera dessa fyra uppdateringar från imagen och sen köra Lpremove.exe som ett steg under deployment. Därefter kan dessa uppdateringar installeras utan att det blir något problem.
Känns stabilt? Inte särskilt. Om fyra uppdateringar i rad under fem månader har orsakat detta problem, vad händer då nästa månad? Vi har i alla fall meddelat Microsoft om detta och har ett öppet ärende, så får vi se vad som händer. Jag kommer posta eventuella uppdateringar i ärdendet här.
PS. För övrigt anser jag att det faktum att man nu måste installera över 200 uppdateringar efter Windows 7 SP1 är rena skämtet, och Microsofts vägran att släppa en ny service pack är förkastligt. Jag förstår att man inte vill förlänga supporttiden, men släpp då allting som en stor ”cumulative update rollup” i så fall.
3 kommentarer
Hej
Har läst lite om din felsökning ovan .. jag har en win 7 med samma problem här .. min tillfälliga lösning
just nu är att ta död på tjänsten Explorer och starta den igen .. då kommer skrivbordet fint 😉 .. men detta måste göras varje morgon .. jag har alltså ingen permanent lösning än 🙁
Author
Det låter som att du då kan starta Task manager när du befinner dig läget med den svarta skärmen? Och då där ifrån döda explorer.exe och starta om den? I så fall är det inte riktigt samma bugg, utan en mer ”vanlig” variant på samma tema. Vanligaste orsaken då brukar vara någon drivrutin. Funkar det att starta i felsäkert läge?
Ja det stämmer ..jag når Task manager i detta läge .. enl. användaren av denna pc så har inget nytt installerats eller uppdaterats … jag har inte testat om den startar i felsäkert läge 😉