Windows 7-prisene klare

[fenderebest]

fenderebest:

Det tar deg ofte mer tid å komme deg inn på serverrommet, koble til kabelen, boote serveren i modusen du trenger etc. Eller skal du kjøre alle servere i debugger modus til enhver tid med kabler tilkoblet? Kortere tid tar det å restarte serveren via en IP basert KVM switch(hvor man også ser blåskjermen), sjekke feilmeldingene og fjerne erfaringsbaserte faktorer som kan være problemet.

 

Ikke minst hvor lang tid tar det å bestille deg, og om du er ledig for oppdrag, for deg å komme til åstedet serveren står og sette i gang feilsøkingen med debuggerkabelen du kobler til laptopen din?

 

 

Legg merke til at maskinen var fullstendig FRYST. Altså ingen blåskjermer og ingen feil logget til hendseslisten i Windows. Mao har man ingenting å gå på når maskinen er restartet. Den eneste effektive måten å feilsøke da blir via en debuggerkabel.

 

Evt om serveren har mulighet for å sende et NMI kan man også gjøre dette - men det er langt ifra alle servere som har og man må uansett være fysisk tilstede. Om serveren har et PS2 keyboard finnes det også innebygget funksjonalitet for å krasje Windows manuelt.

 

Om man skal feilsøke en server som opplever blåskjermer er det mest effektive at bedriften som opplever blåskjermen sender minnedumpene til meg. Da kan jeg feilsøke dem hvor som helst i landet og slipper å måtte komme fysisk ned til bedriften.

 

Det er også mulig å gjøre remote debugging via nettverk.

 

Forøvrig har jeg vært utplassert i diverse IT-bedrifter som ikke driver med annet enn IT-support og jeg må si at flere av teknikerne der har helt håpløse rutiner for feilsøking. De hadde jo flere sertifiseringer og var jo en god del eldre enn meg men måten de feilsøket på imponerte ikke.

 

Feks hadde hele 5 IT-tekinkere vekslet over en periode på 4 dager på å forsøke seg på en enkelt datamaskin fra en viktig kunde. Problemet var at Outlook ville allokere 100mb med minne hver gang en ny mail ble åpnet. Outlook ville heller ikke frigjøre minnet når mailen ble stengt. De hadde da forsøkt flere forskjellige ting som å reinstallere programmet, starte programmet med forskjellige parametre, søkt rundt på nettet ringt til support osv. Av ren nyskjerrighet spurte jeg om jeg kunne få prøve litt og det første jeg gjorde var å spørre meg hvor all denne dataen kom ifra? Så bare for å teste kjørte jeg filemon mens en ny mail ble åpnet for å prøve å få et innblikk i hva som foregikk. Etter å ha åpnet mailen kunne man ganske enkelt se over 10 000 leseoperasjoner fra en bestemt fil i programdata mappen. Siden jeg viste at dette var ulogisk oppførsel og at filer i Programdata mappen som regel ble laget enten når programmet ble installert første gång eller når det ble kjørt, så tok jeg og renamet filen slik at Outlook ikke ville finne den og forhåpentligvis lage en ny. Og ganske riktig - Outlook lagde en ny fil og problemet var helt forsvunnet og det hele hadde tatt meg 5 minutter til forbløffelse fra teknikerne.

 

Så synes det er viktig at teknikerne faktisk jobber litt selv for å aktiv sette seg inn i korrekte måter for feilsøking da dette er ikke noe man lærer av erfaring men av kunnskap.

Endret 28. juni 2009 av fenderebest

[Theo343]

Nei den eneste effektive måten blir ikke en debugger.

 

At 5 teknikere ikke er kjent med gode rutiner for feilsøk, eliminering osv. beviser ingenting i denne sammenhengen. I bunn og grunn utførte du ingenting her som ikke hvem som helst jeg har jobbet med bare siste 10 år ville gjort.

 

Du snakker helt klart mot bedre viten på hva som er vanlig kunnskap hos de fleste i IT bransjen.

Endret 28. juni 2009 av Theo343

[fenderebest]

Forklar gjerne en alternativ måte som er bedre.

 

Og du har helt riktig - problemet var superenkelt var bare sjokkert over at teknikerne ikke klarte å løse det. Det tilsier vel at erfaring ikke er alt.

Endret 28. juni 2009 av fenderebest

[Theo343]

Når en maskin er fryst? Hva med å restarte den og forsøke å finne feilen fremfor å begynne med debugging som man gjerne tar når god erfaring med generelt feilsøk ikke finner feilen eller løser problemet. Jeg har til dags dato alltid klart å finne årsak til feil uten debugging verktøy.

 

Bolson:

Jeg kunne ikke vært mer enig.

Endret 28. juni 2009 av Theo343

[fenderebest]

Når en maskin er fryst? Hva med å restarte den og forsøke å finne feilen fremfor å begynne med debugging som man gjerne tar når god erfaring med generelt feilsøk ikke finner feilen.

 

Bolson:

Jeg kunne ikke vært mer enig.

 

Maskinen er fryst når caps lock indikatoren på keyboardet ikke er responsiv.

Og at den beste måten å feilsøke en fryst datamaskin er via en debuggerkabel er det ikke jeg som har funnet på det er disse gutta her:

http://blogs.msdn.com/ntdebugging/

 

Den eneste alternative måten jeg kunne se for meg som ikke involverer debugging vil være en fryktelig treg metode der man deaktiver/aktiverer tredjepartsdrivere - men dagens datamaskiner har så mange at dette ville gått veldig tregt og selv om man deaktiverte en driver og problemet forsvant ville det ikke være noen god garanti på at denne driveren faktisk var problemet.

 

Som er da de mest erfarne teknikerne innenfor Windows feilsøking som tenkes kan. De fleste teknikkene jeg bruker er enten hentet fra bloggen her eller andre bøker om Windows feilsøking. Feks er Advanced Windows Debugging en uvurderlig bok som beskriver feilsøking innenfor Windows applikasjoner.

Endret 28. juni 2009 av fenderebest

[Gapatrosten]

I oppgraderingsprogrammet som skal fungere fra den 26 fins det ikke Norsk ? verson har jeg hørt er det noen som vet noe rundt det ??

[Mr.M]

I oppgraderingsprogrammet som skal fungere fra den 26 fins det ikke Norsk ? verson har jeg hørt er det noen som vet noe rundt det ??

Da må du ha hørt feil

[Theo343]

Jeg vet når en maskin er fryst.

[fenderebest]

Så bra for deg da! Da har du sikkert også innsett at den beste måten å feilsøke en fryst maskin er via en debuggerkabel

Endret 28. juni 2009 av fenderebest

[Theo343]

Vi lar dette tullpratet ligge nå. Helt topp at du brenner for debugging, men det er mange veier til Rom.

[fenderebest]

Hvilken annen alternativ måte kan realistisk løse problemet med en datamaskinen som er fryst på en like effektiv og logisk måte? Siden dette er en godt dokumentert metode fra Microsofts egne teknikere må jeg si at jeg lurer litt på hvilken metode som kan være bedre.

Jeg siterer forøvrig:

Jeg har til dags dato alltid klart å finne årsak til feil uten debugging verktøy.

 

Noe som fort kan tolkes slik at du aldri har brukt debuggings verktøy for å feilsøke? Og dermed kan du ikke skråsikkert påstå at debugging er en dårlig metode?

Endret 28. juni 2009 av fenderebest

[Theo343]

debugging kabel, som er hele poenget ditt her. Procmon, Regmon og Filemon vil jeg ikke kalle spesielt debugging verktøy, da er man mer inne på verktøy som analyserer minnedumper for deg.

Endret 28. juni 2009 av Theo343

[fenderebest]

Greit nok du har aldri brukt en debuggingkabel. Men hvilken metode skulle du bruke da for å feilsøke en fryst maskin.

 

Procmon og Filemon er feilsøkingsverktøy som ikke analyserer noe. Det gir deg bare rådataene som du kan konkludere med selv.

 

Det eneste jeg klarte å finne var:

"Hva med å restarte den og forsøke å finne feilen"

 

Noe som må være noe av det vageste jeg har hørt, du kan ikke finne feilen når beviset er borte. Det blir isåfall ren gjetting. Gjetting er ikke en del av god feilsøking. Gjetting er og blir for amatører og husmødre.

Endret 28. juni 2009 av fenderebest

[Theo343]

Om jeg ikke tar feil har jeg skrevet det tidligere

[Bolson]

Ikke for å være stygg, men skulle gjerne sett debugging av cobolkode ved hjelp av debuggingkabel. fenderbest, du har garantert greie på ditt begrensa felt, men virkeligheten er ikke særlig begrensa når det gjelder feilkilder, og at maskiner fryser er ikke det mest vanlige problemet. Tror Theo343 kan bekrefte dette.

 

Men egentlig er dette OT og lite relevant for prisen på windows 7.

[fenderebest]

Dere kan gjerne tro dere vet mere en de ledende teknikerne hos Microsoft men da slår det meg at det mest begrensede her er deres egen tenkegang.

[Bolson]

Tviler på at det er mange ledende teknikere hos Microsoft som i det hele tatt kan debugge cobolkode.

 

Og jeg tviler ikke på at det du kan er meget nyttig i gitte feilsituasjoner.

 

Tror hverken Theo343 eller undertegende på noen måte tror vi kan mer enn ledende teknikere hos Microsoft når det gjelder Windows sitt "indre liv". Vi vet at det kan vi ikke. Men vi kan sannsynligvis langt mer på andre områder, også når det gjelder å finne, isolere, og rette feil. Selv om det er generell metodikk for å finne, isolere og rette feil, vil både verktøy, metode etc variere fra gang til gang. Personer med mye erfaringer "lukter" i enkelte tilfeller feilkildene.

 

Og vi er neppe særlig begrenset av oss.

 

Men dette er OT, så vi kan vel avslutte her.

[fenderebest]

En Windows tekniker skal kunne finne og utbedre absolutt alle feil tenkelige ved en datamaskin som kjører Windows. Og er derfor ikke begrenset til et fåtall verktøy, men gjelder å vite hvilket verktøy som er korrekt for en gitt situasjon.

 

Det holder feks ikke å si at du har funnet en driver som du mener er problemet. Man må kunne finne logisk bevis på hva nøyaktig driveren gjør galt og også hvordan dette kan rettes. Selv fra drivere/moduler fra en tredjepart.

 

Her er jo det man skal kunne, sjekk selv hvor mye av dette dere har vært borti:

 

Identifying Architectural Components (16%)

Identify memory types and mechanisms.

This objective may include but is not limited to: nonpaged vs. paged; memory descriptor lists; physical memory vs. logical memory; address translation; heap memory.

Identify I/O mechanisms.

This objective may include but is not limited to: Plug and play; IRQL levels; I/O request packets (IRPs); I/O manager; device stacks; filter drivers; timers

Identify subsystems.

This objective may include but is not limited to: Object manager; cache manager; process manager; memory manager; security reference monitor

Identify processor functions and architecture.

This objective may include but is not limited to: Interrupts; processor affinity; system service calls; 64-bit vs. 32-bit

Identify process and threads.

This objective may include but is not limited to: Process environment block (PEB), thread environment block (TEB); thread scheduling, states and priority

Designing Solutions (15%)

Optimize a system for its drivers.

This objective may include but is not limited to: driver signing; identifying filter drivers; timers and deferred procedure calls (DPCs); system worker threads; Driver Verifier

Design applications.

This objective may include but is not limited to: Application Verifier; gflags; kernel mode vs. user mode threads; structured exception handling (SEH); memory mapped files; authentication mechanisms; synchronization primitives

Deploy compatible applications.

This objective may include but is not limited to: Application Verifier; Application Compatibility Toolkit (ACT); gflags

Identify optimal I/O models for applications.

This objective may include but is not limited to: synchronous vs. asynchronous I/O; I/O completion ports; multithreaded applications

Monitoring Windows (14%)

Monitor I/O latency.

This objective may include but is not limited to: Perfmon; disk I/O; application performance; device I/O

Monitor I/O throughput.

This objective may include but is not limited to: filter drivers; cache manager; xperf; kernrate

Monitor memory usage.

This objective may include but is not limited to: nonpaged vs paged pool; user memory vs. kernel memory; debugging memory leaks; memory corruption; heap corruption

Monitor CPU utilization.

This objective may include but is not limited to: thread time; kernel vs. user time; thread states; Perfmon; WinDbg; Xperf; Kernrate

Monitor handled and unhandled exceptions.

This objective may include but is not limited to: Adplus; Dr Watson; Windows Error Reporting (WER); default post-mortem debuggers; exception handling

Analyzing User Mode (18%)

Analyze heap leaks.

This objective may include but is not limited to: UMDH (User-mode dump heap); user mode stack tracing; WinDbg; Application Verifier; Gflags; Perfmon

Analyze heap corruption.

This objective may include but is not limited to: Page heap; WinDbg; Application Verifier; Gflags

Handle leaks.

This objective may include but is not limited to: Procmon (Process Monitor); Perfmon; WinDbg; htrace; Process Explorer; Handle.exe

Resolve image load issues.

This objective may include but is not limited to: Tlist; loader snaps; dll dependencies; application manifests; 64-bit applications vs. 32-bit applications; tasklist

Analyze services and host processes.

This objective may include but is not limited to: sc.exe; services; service dependencies; service isolation; services startup types; service registry entries

Analyze cross-process application calls.

This objective may include but is not limited to: RPC; LPC; shared memory; named pipes; process startup; winsock

Analyze the modification of executables at runtime.

This objective may include but is not limited to: WinDbg; image corruption; detours; hot patches

Analyze GUI performance issues.

This objective may include but is not limited to: spy++; message queues; Application Verifier; TraceTools; ATL Trace; Task Manager

Analyzing Kernel Mode (19%)

Find and identify objects in object manager namespaces and identify the objects’ attributes.

This objective may include but is not limited to: Winobj.exe; symbolic links; object namespace; security descriptors; global namespace; device objects; file objects; object manager; semaphores

Analyze Plug and Play (PnP) device failure.

This objective may include but is not limited to: removal failures; global device list; WinDbg; device adds and removes; power handling

Analyze pool corruption.

This objective may include but is not limited to: Driver Verifier; WinDbg; pool tags; Poolmon; guard pages

Analyze pool leaks.

This objective may include but is not limited to: WinDbg; poolmon; Driver Verifier; crash dump analysis; paged and nonpaged pool; cache trimming

Isolate the root cause of S state failure.

This objective may include but is not limited to: System power states and transitions; power IRP handling

Analyze kernel mode CPU utilization.

This objective may include but is not limited to: kernrate.exe; WinDbg; deadlocks; Performance monitoring; event tracing

Debugging Windows (18%)

Debug memory.

This objective may include but is not limited to: Heap; pool; virtual memory vs. physical memory; stack; analyzing crash dumps and user dumps

Identify a pending I/O.

This objective may include but is not limited to: WinDbg; deadlocks; I/O manager; IRP processing

Identify a blocking thread.

This objective may include but is not limited to: thread state; locks; synchronization objects

Identify a runaway thread.

This objective may include but is not limited to: thread priorities; processor affinity; Perfmon; kernrate

Debug kernel crash dumps.

This objective may include but is not limited to: WinDbg; DPCs; Assembler; forcing kernel crash dumps; trap processing; register usage; call stack composition (prolog/epilog); processes vs. threads

Debug user crash dumps.

This objective may include but is not limited to: dump types; forcing user crash dumps; gflags; system resource utilization (CPU, disk, network; memory)

Set up the debugger.

This objective may include but is not limited to: WinDbg; physical connection (USB, rs-232, 1394); boot.ini; bcdedit; remoting; NMI; debugging system processes

 

Endret 28. juni 2009 av fenderebest

[Theo343]

Jeg ønsker deg lykke til i karrieren, men ingen av oss orker denne diskusjonen med deg lenger.

Endret 28. juni 2009 av Theo343

[fenderebest]

Greit, da setter vi strek her.