Пришло письмо с вопросом:
Обнаружилась следующая проблема: Наша программа сохраняет и считывает последнюю открытую ею директорию в разделе реестра, где сохраняют последние посещенные ими директории и другие программы, а именно в ветке «HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU». Это в 32-х разрядной версии. Но оказывается, что в 64-х разрядной версии данной ветки реестра в узле HKCU не существует, а она находится в «HKEY_USERS\<некий идентификатор пользователя>\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU». Так вот вопрос: как мне программно доступиться к этой ветке, если идентификатор пользователя неизвестен? Или, может, есть способ узнать этот идентификатор каким-то образом? А может где-то есть в реестре зеркало этой ветки, к которой можно получить доступ более простым способом?
Обнаружилась следующая проблема:
Наша программа сохраняет и считывает последнюю открытую ею директорию в разделе реестра, где сохраняют последние посещенные ими директории и другие программы, а именно в ветке «HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU». Это в 32-х разрядной версии. Но оказывается, что в 64-х разрядной версии данной ветки реестра в узле HKCU не существует, а она находится в «HKEY_USERS\<некий идентификатор пользователя>\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU».
Так вот вопрос: как мне программно доступиться к этой ветке, если идентификатор пользователя неизвестен? Или, может, есть способ узнать этот идентификатор каким-то образом? А может где-то есть в реестре зеркало этой ветки, к которой можно получить доступ более простым способом?
Сижу я сегодня на работе, никого не трогаю, отладчиком отладчик отлаживаю. А что, отладчик - тоже человек программа. Тем более что немногим ранее я его немножко совсем поломал, пытаясь добавить поддержку некоей конфигурации, которая текущей реинкарнацией отладчика не поддерживается. Ну вот, запускаю я его примерно вот таким образом:
windbg.exe kd.exe -k com:port=com1,baud=115200
…и замечаю, что что-то не так. А именно - опять сломался наш корпоративный прокси. А я как раз хотел посмотреть в… ну скажем MSDN. Попробовал и так и сяк. Не работает, вылетает по таймауту. Ну хорошо, но тут начитают происходить еще более мистические вещи. Outlook вдруг перестает реагировать мышь и клавиатуру; IE вообще не запускается – процесс стартует, но окно не показывается. Несколько подозрительно для проблем с прокси.
Главная проблема с хуками состоит не в том, как зацепиться, а в том, как отцепиться и ничего не порушить. К примеру, приходит недавно письмо:
We recently saw an AV in stress where our vectored exception handler was called after our dll was unloaded. After investigating the issue, it seems like removing the vectored exception handler does not wait for all users of that exception handler to finish (and does not even remove the exception handler from list for future users if there is one current user). So, there seems to be no way to synchronize removing the exception handler and the dll unloading – any synchronization within the exception handler is useless since the exception thread may be about to call the exception handler.
Недавно мы наблюдали падение приложения во время стрессового тестирования, вызванное тем, что векторный обработчик исключения был вызван после того, как наша DLL была выгружена из памяти. В процессе расследования выяснилось, что, похоже, снятие векторного обработчика исключения не ожидает, пока все пользователи этого обработчика закончат работу (и даже не удаляет обработчик для будущих пользователей, если обработчик в данный момент используется). Так, похоже, что не существует способа синхронизировать снятие векторного обработчика и выгрузку DLL – любая синхронизация в пределах обработчика исключения бесполезна, поскольку поток, в котором произошло исключение, может только готовится вызвать обработчик исключения.
Писал я тут свой первый драйвер для сетевой карты. Взял, как полагается, за основу готовый образец драйвера. Выкинул всю аппаратно-зависимую часть. Добавил свою. По ходу дела выяснил, что tear-down код в примере отсутствует напрочь, чтение стандартной конфигурации не сделано, кругом hardcoded константы. В общем, обычная история, что вы хотите от образца?
Дописал до работающего состояния, протестировал скорость TCP/IP соединения. Получается примерно 3 MByte/sec на одно соединение, около 12 MByte/sec – пиковая пропускная способность нескольких параллельных соединений. Маловато для 1 Gbit/sec соединения.