Не так давно нужно было разобраться с падением одного драйвера на Windows 8 Developer Preview AMD64. Исходные данные на первый взгляд хорошие - полный дамп памяти при падении. Но при попытке открытия отладчик WinDbg крепко задумался на несколько секунд, после чего выдал многозначительное окно:
The parameter is incorrect.
Хотя отладчик у меня не самый старый (WinDbg:6.12.0002.633 AMD64), решил попробовать WinDbg из WDK для Windows 8 Developer Preview. Результат - дамп замечательно открылся.
Так что, видимо, пришло время снова обновлять WinDbg даже не из-за новых возможностей (возможно напишу о нововведениях в Debug Engine чуть позже, отдельной статьей), а из-за банальной работоспособности: для анализа новых дампов.
Updated (10.02.2012)
Как оказалось, о нововведения не надо писать, про них уже есть пост в блоге Microsoft'а: Debugger Engine (DbgEng) updates in the Windows 8 Developer Preview. А вот официальная документация в MSDN пока не обновлена.
От себя скажу, что мне нравится введение привязки в точке останова к GUID'у: IDebugBreakpoint3::GetGuid и IDebugControl5::GetBreakpointByGuid. Раньше точку останова можно было идентифицировать по численному идентификатору (IDebugControl::GetBreakpointById) и порядковому номеру (IDebugControl::GetBreakpointByIndex). Но оба эти параметра могут идентифицировать точку останова в конкретный момент времени, а работать с break-point'ами приходится из обратных вызовов, после трассировки и тому подобное. И тут никто не даст гарантии что за это время пользователь через команды не изменил точки останова.
Остальные изменения нужно будет пощупать руками. Возможно что-то из нового в скором времени попадет в PyKd :)
ΞρεΤΙκ