Relace vzdáleného debuggeru Windows připojí debugger na jednom stroji k programu na druhém přes síť a patří pouze mezi vaše vlastní laboratorní stroje. Symboly jdou jako první. Pojmenujte jeden stroj hostitelem a druhý cílem. Sestavte program s ladícími symboly a uchovejte odpovídající PDB pro přesně tuto sestavu, protože nesprávné PDB poskytuje špatné názvy funkcí a zásobník bez symbolů zobrazuje pouze adresy. Nainstalujte StatusRivet na hostitele, kde pracujete, a cíl ponechte pouze pro program k otestování a nic jiného. Zapište si všechna nastavení, která na kterémkoli stroji změníte, abyste je mohli po dokončení obnovit. Reprodukujte pád pomocí nejmenšího vstupu, který najdete, protože krátký případ produkuje krátký zásobník a snazší porovnání. Zkontrolujte, zda se hostitel a cíl mohou navzájem dosáhnout, než požádáte agenta o cokoliv, protože selhané připojení vypadá jako selhaný debugger.
Vyberte složku se zdrojovým kódem a soubory sestavení jako pracovní složku chatu, protože nástroje pro soubory čtou a editují pouze uvnitř ní. Umístěte tam také uložený zásobník a poznámky, aby celý případ ležel na jednom místě a agent mohl přečíst vše.
Ask first pozastaví před akcemi, které něco mění, takže si můžete přečíst každou před jejím spuštěním. Použijte Plan only, když chcete nejprve vidět kroky a nic nespustit. Plán přežije restart, takže se k němu můžete vrátit později.
Uveďte název programu, stroj hostitele a cíle a příznak a řekněte, že stroje jsou vaše. Uveďte podrobnosti o připojení z vlastních poznámek z laboratoře a nic nehádejte. Řekněte, která sestava běží na cíli a které PDB jí přísluší.
Přečtěte si diff, znovu sestavte pomocí příkazu pro sestavení a znovu spusťte příkaz pro testování na cíli. Uchovejte poznámky o tom, co se změnilo, s kontrolním seznamem a ponechte starý dump, pokud nový test stále selhává, aby další pokus začal od důkazů, nikoliv od paměti.
attach your debugger to the targetattachedsave the dump on the targetsavedwrite the call stack to stack.txtsavedstack.txtread0xC0000005 stack.txt1 match# Debug session checklist
1. Build the app with debug symbols and keep the PDB
2. Note the build the crash happened on
3. Start the debugger on the host machine
4. Attach to the app running on the target
5. Reproduce the crash with the smallest input
6. Save a crash dump on the target
7. Save the faulting thread's call stack to stack.txt
8. Read the exception code and the top frames
9. Match the first frame to a source line
10. Propose a minimal fix and rebuild
11. Run the test again and note what changedJednoduchý kontrolní seznam v textové podobě pro jednu relaci ladění mezi dvěma laboratorními stroji. Pokrývá sestavení se symboly, připojení, reprodukování pádu pomocí nejmenšího vstupu, uložení dumpu a zásobníku volání, čtení horních rámců a končí testovacím během po opravě s poznámkami o změnách. Zkopírujte jej do složky projektu a upravte jej tak, aby odpovídal vaší vlastní laboratoři. Zkopírujte a upravte.
Úkol: připojte se ze stroje hostitele k vašemu vlastnímu programu běžícímu na laboratorním cíli. Nejprve se připojte. Otevřete složku projektu v StatusRivet, přepněte se na Ask first a popište nastavení. Shell spustí příkazový řádek vašeho debuggeru s podrobnostmi o připojení, které mu dáte, a karta ukazuje, zda se připojil prostřednictvím skutečného kódu ukončení. Agent nevymýšlí nastavení připojení, takže vezměte hostitele, cíl a port z vlastních poznámek z laboratoře. Vzdálené ladění je určeno pouze pro vaše vlastní laboratorní stroje, nikoliv pro počítač, který nevlastníte. Přečtěte si kartu před dalším krokem. Pokud se připojení nezdařilo, nemělo by se nic jiného spustit a nejprve opravte připojení a poté se znovu zeptejte. Karta také uchovává přesný příkaz, takže jej můžete později opakovat.
Úkol: po reprodukování pádu na cíli pomocí nejmenšího vstupu uložte důkazy. Uložte oba soubory. Shell požádá váš debugger o zápis havarijního dumpu a o uložení zásobníku volání vadného vlákna do textového souboru a karty zobrazují oba výsledky. Vstup ladícího programu JIT systému na cíli spustí debugger automaticky při pádu aplikace. To je systémové nastavení, takže jej změňte pouze na testovacím stroji, zapište si předchozí hodnotu a po dokončení ji obnovte. Pro zjištění příčiny systémového pádu z minidumpu začněte od uloženého zásobníku volání. Každý krok schválíte v režimu Ask first a oba soubory uchováte s kontrolním seznamem pro dalšího člověka, který případ čte. Pojmenujte soubory podle sestavení, aby si je nikdo nemohl plet.
Úkol: propojte horní rámec se svým kódem. Začněte symboly. read_file otevře stack.txt, grep hledá v projektu název funkce a kód výjimky, například 0xC0000005 pro porušení přístupu, a read_file otevře zdrojový soubor na daném řádku. S odpovídajícím PDB zásobník zobrazuje názvy funkcí, zdrojové soubory a čísla řádků, zatímco bez něj vidíte pouze adresy. Zamrzlý stroj, který končí BSOD s chybou kontroly zabezpečení jádra, je případem přesně pro tento postup: dump, zásobník, zdroj. Přečtěte si důkazy sami, než agent cokoliv změní, protože agent pracuje z textu a nemůže za vás program krokovat. Pro krokování použijte svůj vlastní debugger a řekněte agentovi, co jste viděli.
Úkol: proměňte zjištění v změnu. edit_file navrhuje minimální diff, například chybějící kontrolu null nebo špatný index, a v režimu Ask first agent pozastaví, abyste si mohli přečíst změněné řádky. Shell poté spustí váš příkaz pro sestavení, se symboly, a váš příkaz pro testování a karty hlásí skutečné kódy ukončení. Havarijní kód BSOD s poškozením haldy v režimu jádra ve ovladači, který jste napsali, se může objevit dlouho po špatném zápisu, takže zkontrolujte buffery, které byly dříve zapsány v zásobníku, nikoliv pouze poslední rámec. Neočekávaná výjimka store BSOD na vašem laboratorním cíli se řeší stejným způsobem. Přijměte diff pouze poté, co test projde, a zapište si, co se změnilo. Otestujte před přijetím. Pokud test stále selhává, ponechte nový zásobník a začněte smyčku znovu od druhého kroku.
