Сесія віддаленого відлагоджувача Windows підключає відлагоджувач на одному комп'ютері до програми на іншому через мережу, і вона призначена лише для ваших власних лабораторних машин. Спочатку — символи. Назвіть один комп'ютер хостом, а інший — мішенню. Зберіть програму з символами відладки та збережіть відповідний PDB для цього точного збіру, оскільки невідповідний PDB дасть неправильні імена функцій, а стек без символів покаже лише адреси. Встановіть StatusRivet на хості, де ви працюєте, а мішень залиште для програми, що перевіряється, і нічого більше. Запишіть будь-які зміни налаштувань на обох комп'ютерах, щоб ви могли відновити їх пізніше. Відтворіть аварію за допомогою найменшого вхідного набору даних, який ви можете знайти, оскільки короткий випадок дає короткий стек і простіше порівняння. Переконайтеся, що хост і мішень бачать один одного, перш ніж просити агента щось зробити, оскільки невдале підключення виглядає як невдале відлагодження.
Виберіть папку з вашим вихідним кодом та файлами збірки як робочу папку чату, тому що інструменти файлів читають і редагують лише всередині неї. Покладіть туди збережений стек та нотатки, щоб весь випадок був в одному місці, і агент міг прочитати все.
Ask first робить паузу перед діями, які щось змінюють, щоб ви могли прочитати кожну дію перед її запуском. Використовуйте Plan only, коли хочете спочатку побачити кроки і нічого не запускати. План зберігається після перезавантаження, тому ви можете повернутися до нього пізніше.
Назвіть програму, хост і мішень, а також симптом, і скажіть, що комп'ютери ваші. Надайте деталі підключення з ваших власних лабораторних нотаток і не вгадуйте жодного з них. Скажіть, який збір працює на мішені, і який PDB їй належить.
Прочитайте diff, зберіть знову за допомогою вашої команди збірки та запустіть вашу команду тестування знову на мішені. Зберігайте нотатки про те, що змінилося, разом із чеклистом, і зберігайте старий дамп, якщо новий тест все ще не вдається, щоб наступна спроба починалася з доказів, а не з пам'яті.
attach your debugger to the targetпідключеноsave the dump on the targetзбереженоwrite the call stack to stack.txtзбереженоstack.txtпрочитано0xC0000005 stack.txt1 збіг# 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 changedЧеклист у текстовому форматі для однієї сесії відлагодження між двома лабораторними комп'юторами. Він охоплює збірку з символами, підключення, відтворення аварії за допомогою найменшого вхідного набору даних, збереження дампа та стека викликів, читання верхніх кадрів і закінчується тестовим запуском після виправлення, з нотатками про те, що змінилося. Скопіюйте його в папку вашого проєкту та відредагуйте відповідно до вашої власної лабораторії. Скопіюйте та відредагуйте.
Завдання: підключіться з хоста до вашої власної програми, що працює на лабораторній мішені. Спочатку підключіться. Відкрийте папку проєкту в StatusRivet, перемкніться на Ask first та опишіть налаштування. Shell запускає командний рядок вашого відлагоджувача з деталями підключення, які ви йому надаєте, а картка показує, чи підключився він через реальний код виходу. Агент не вигадує налаштування підключення, тому беріть хост, мішень та порт з ваших власних лабораторних нотаток. Віддалене відлагодження призначене лише для ваших власних лабораторних машин, ніколи для комп'ютера, яким ви не володієте. Прочитайте картку перед наступним кроком. Якщо підключення не вдалося, нічого іншого не повинно запускатися, і ви спочатку виправляєте підключення, а потім запитуєте знову. Картка також зберігає точну команду, тому ви можете повторити її пізніше.
Завдання: після відтворення аварії на мішені за допомогою найменшого вхідного набору даних збережіть докази. Збережіть обидва файли. Shell просить ваш відлагоджувач записати дамп аварії та зберегти стек викликів потоку, що викликав аварію, у текстовий файл, а картки показують обидва результати. Запис відлагоджувача JIT Windows на мішені автоматично запускає відлагоджувач, коли програма аварійно завершує роботу. Це системне налаштування, тому змінюйте його лише на тестовій машині, запишіть попереднє значення та відновіть його після цього. Щоб знайти причину системної аварії за допомогою мінідампа, почніть зі збереженого стека викликів. Ви затверджуєте кожен крок у режимі Ask first, і ви зберігаєте обидва файли з чеклистом для наступної людини, яка читатиме випадок. Назвіть файли за збором, щоб їх не переплутали.
Завдання: підключіть верхній кадр до вашого коду. Почніть з символів. read_file відкриває stack.txt, grep шукає в проєкті ім'я функції та код винятку, наприклад 0xC0000005 для порушення доступу, а read_file відкриває вихідний файл у цьому рядку. З відповідним PDB стек показує імена функцій, файли та номери рядків, а без нього ви бачите лише адреси. Завислий комп'ютер, який закінчується BSOD із перевіркою безпеки ядра, — це випадок саме для цієї процедури: дамп, стек, код. Прочитайте докази самостійно, перш ніж агент щось редагуватиме, тому що агент працює з текстом і не може крокувати по програмі за вас. Для крокування використовуйте свій власний відлагоджувач і повідомте агенту, що ви побачили.
Завдання: перетворіть знахідку на зміну. edit_file пропонує мінімальний diff, наприклад, відсутню перевірку на null або неправильний індекс, і в режимі Ask first агент робить паузу, щоб ви могли прочитати змінені рядки. Shell потім запускає вашу команду збірки, з символами, та вашу команду тестування, а картки повідомляють реальні коди виходу. Корупція пам'яті в режимі ядра BSOD у драйвері, який ви написали, може проявитися довго після поганого запису, тому перевірте буфери, записані раніше в стеці, а не лише останній кадр. Несподіваний виняток зберігання BSOD на вашій лабораторній мішені обробляється так само. Приймайте diff лише після успішного тестування та запишіть, що змінилося. Тестуйте перед прийняттям. Якщо тест все ще не вдається, збережіть новий стек і почніть цикл знову з другого кроку.
