Mark russinovich în limba rusă

Cazul se referă la categoria mea preferata de cazuri în care am fost folosind propriile lor instrumente pentru a aborda problema, care ma afectat cel mai mult. Acest caz este, în principiu poate afecta pe oricine, mai ales cei care călătoresc mult, și demonstrează utilizarea unor caracteristici ale programului Monitor de proces, pe care mulți nu-și dau seama, ceea ce îl face ideal pentru descrierea și difuzarea.

Povestea se desfășoară în ultima săptămână, când m-am dus la Orlando pentru a vorbi la conferinta, Microsoft TechEd America de Nord. Când am fost acolo, am fugit într-o întârziere de cinci minute, atunci când vă conectați la sistemul Windows 7, urmat de un ecran negru:

Am folosit pentru a atribui întârzieri individuale, cum ar fi acest lucru, în detrimentul unei probleme de rețea, conferințe frecvente cu WiFi-rețeaua lor, oferite de hotel. Dar am în mod constant a alerga până la această problemă prin comutarea între Windows 8 instalat pe sistemul meu laptop pentru testare și de prezentare, și Windows 7 în cazul în care există instrumente de dezvoltare. Ia blocat în acea perioadă de timp, calculatorul - nu este suficient să spunem, va fi oarecum iritat.

Pentru prima dată, când a existat un ecran negru, am restartat forțat după câteva minute de așteptare, pentru că gândul că ea a fost spânzurat. Când m-am Întârzierea a survenit pentru a doua oară, am fost nevoit să aștepte și să se confrunte cu faptul frustrant că sistemul meu este în afara de ordine. Când am ieșit și a venit din nou, fără a fi nevoie să repornească, întârzierea nu a avut loc. Aceasta se întâmplă numai după o repornire, pe care am făcut-o prin comutarea între Windows 7 și Windows 8. Ce este cel mai trist, ori de câte ori am reboot, m-am grăbit la următoarea mea prezentare, așa că am fost nevoit să îndure inconveniente pentru câteva zile, până când a găsit posibilitatea de a explora problema.

După ce a avut un moment liber, am lansat programul Sysinternals Autorun. Programe avansate de pornire de control al mass-media pentru a preveni toate imaginile aflate pe resurse partajate în rețea. Din experiența din trecut, începe Autorun pe laptop-ul meu am fost conștient de faptul că serviciul Microsoft configurează numărul de sarcini programate pentru a rula fișiere lot, situat pe cota de rețea corporativă, și care sunt suspectate că timeout-urile sunt asociate cu o încercare de a le rula:

Am ieșit și sa întors, păstrați degetele încrucișate, dar întârzierile erau încă în vigoare. Următorul pas, am încercat să intre în contul local pentru a vedea dacă problema este, sau doar asociat cu profilul meu la nivel de sistem. Nici o intarziere. Acesta este un semn pozitiv, deoarece aceasta înseamnă că problema nu ar fi nici a fost asociata cu ceea ce poate fi relativ ușor de a stabili după descoperirea.

Acum, scopul meu a fost de a stabili că continuat trecerea la desktop. Am nevoie de o modalitate de a vedea ce se întâmplă în timpul înregistrării în sistem imediat după descărcare. Metoda, imediat vine în minte - pentru a utiliza Sysinternals Process Monitor pentru a înregistra evenimentele procesului de boot. Process Monitor - un instrument care înregistrează operațiuni la nivel de sistem cu sistemul de fișiere, registru, procese, DLL, iar rețeaua - este în măsură să înregistreze acțiunea din primele etape ale ghetei până când sistemul se închide sau până când executați Monitor interfața cu utilizatorul de proces. Am ales pentru a descărca o intrare din meniul Options și a deschis dialogul de intrare de pornire:

Acest dialog vă permite să personalizați programul pentru colectarea de evenimente de monitorizare în timp ce urme de descărcări, care sunt instantanee periodice stive de fire. Am ales-o secundă urme, în speranța că, chiar dacă nu ne-ar observa operații, explica întârzierea, pot găsi o soluție de stive de fire care au fost activi chiar înainte de o întârziere sau atunci când a avut loc.

Din păcate, filtrul de curățat fereastra de ieșire, spulberând speranțele mele găsi rapid un indiciu.

Ceea ce sugerează că, probabil, secvența proceselor care rulează la logare ar putea provoca ceva de genul asta, am deschis procesul de dialog de lemn din meniul Instrumente. Acest dialog arată relația părinte-copil pentru toate procesele active, cu intrări jurnal care de încărcare caz înseamnă toate procesele care rulează la inițializare și de conectare. Concentrându-se pe winlogon.exe, managerul de Log on interactiv, am observat că procesul a început Atbroker.exe când am intrat acreditările dvs., și apoi userinit.exe atunci când, în cele din urmă, spațiul de lucru a apărut:

Cheia pentru rezolvarea puzzle-ului este într-o lungă pauză între cele două evenimente. Am știut Logonui.exe pur și simplu afișează o interfață pentru utilizator de intrare, și Atbroker.exe - un mecanism de sprijin pentru trecerea de la interfața de intrare la sesiunea de utilizator, eliminând pauză, cel puțin la început. Ecran negru dispare atunci când userinit.exe de pornire, astfel încât procesul său părinte Winlogon.exe a rămas sub suspiciune. Am creat un filtru pentru a include numai evenimentele de Winlogon.exe și a adăugat un timp relativ coloană pentru a controla cu ușurință atunci când evenimentul a avut loc relativ la începutul descărcării. Când m-am uitat la rezultatele, imediat am văzut că o întârziere de aproximativ șase minute, dar în acea perioadă de timp, nu există nici o activitate care să indice cauza sa:

evenimentele de urmărire sunt excluse în mod implicit, așa că am făcut clic pe butonul trasor filtru eveniment pe bara de instrumente pentru a le include în revista, în speranța că vor pune în lumină asupra problemei:

Pentru a reduce dimensiunea fișierului jurnal, trasor Process Monitor surprinde fir stive numai în cazul în care firul se execută în ultimul moment, care a fost înregistrată în jurnal. Deci, aș dori să se uite la linia fluxului eveniment la începutul întârziere, dar ochii mei au căzut pe fiecare a doua secvență repetată a acelorași patru fluxuri pe parcursul întregii perioade a existenței unui ecran negru:

Am fost destul de sigur că orice flux ar opri a face unele acțiuni la începutul intervalului, și a fost adormit pe restul lungimii sale, atât de sceptic că oricare dintre aceste fluxuri este legată de problema, dar, cu toate acestea, în valoare de petrece câteva secunde, să se uite la ei. Am deschis proprietățile de dialog în cazul în care unul dintre aceste grupuri prin dublu-clic pe eveniment și activat stiva fir pagina, aproape în speranța că numele funcției de apelare în răspunsul prompt stivă.

Când am lansat primul sistem Process Monitor am configurat pentru a obține simboluri pentru imagini Windows de pe serverul de simboluri publice Microsoft folosind mecanismul de DLL de depanare a instrumentelor de depanare pentru Windows. pentru a vedea într-un cadru de stiva nume semnificative funcții module executabile pentru Windows, nu doar o schimbare în fișierele.

Stiva primul flux flux îl definește ca „o mașină de stat» Winlogon de bază în așteptarea unele necunoscute de avertizare, și nu conține nimic interesant:

Stiva firul următor, de asemenea, nu explică nimic care să indice faptul că fluxul este un fir comun de execuție:

Stivă treilea flux a fost mult mai interesant. El a fost un multi-nivel, inclusiv apeluri de funcții multiple UNC Provider (MUP) și driverele clientului DFS responsabil pentru accesul la serverul de fișiere:

Am fugit prin lista mai departe pentru a vedea cadrele situate deasupra stivei, și numele uneia dintre funcțiile, WLGeneric_ActivationAndNotifyStartShell_Execute. S-a confirmat faptul că acest flux și este responsabil pentru problema, din moment ce ruleaza pe desktop shell:

Următoarea funcție cadru, WNetRestoreAllConnectionsW. cu apeluri ulterioare la funcțiile de server de fișiere, ea ma condus la concluzia că Winlogon a încercat să restabilească conformitatea cu literele unităților de server de fișiere înainte de a continua lansarea unui shell și să dea acces la spațiul de lucru. Am deschis Explorer, amintindu-ne că am avut două drive-uri care sunt afișate pe unități de rețea partajate aflate pe calculatoarele din rețeaua Microsoft, unul pentru sistemul meu de dezvoltare, cealaltă pentru resursă internă a Sysinternals, unde am publicat versiunile preliminare ale utilităților. In timp ce la conferința, nu am avut acces la intranet, astfel încât Winlogon nu le-a putut conecta în timpul procedurii de autentificare, și în cele din urmă, după multe minute, a dat:

Sigur, el a găsit otgadku, am făcut clic pe butonul din dreapta al mouse-ului pe fiecare resursă, și deconectați-l. Am restartat laptopul pentru a verifica fix (sau, mai degrabă, o soluție), și o mare satisfacție lui era convins că timpul procedurilor de intrare, a luat doar câteva secunde înainte de apariția a desktop-ului. Cazul a fost închis! Examinati de ce aceste întârzieri sunt destul de mult, am avut nici timp, nici nevoia. Morala acestei povești nu este problema în sine, ci mai degrabă modul de utilizare a instrumentelor Sysinternals și tehnici de depanare pentru a rezolva problemele.

Și, de asemenea, puteți viziona înregistrări ale tuturor discursurilor de la ambele evenimente pe site-urile lor respective:

Sper că va plăcut această afacere!