#3043065 ? Смирился бы с мыслью, что запускать современный софт на устаревшей ОСи — плохая идея, чреватая постоянными проблемами. И либо постарался обновить систему на старом ноуте, либо пересел бы уже на новый, давненько купленный, но так и валяющийся без дела.
А что сделал я? Первым делом запустил дебагер. Почему-то была наивная уверенность в том, что место возникновения ошибки должно находиться недалеко от вывода сообщения об этой ошибке. Бряк на MessageBoxA(W) и несколько часов отладки показали, что я (внезапно!) недооценил масштаб и сложность приложения. Там сначала один метод выполняет ряд операций по инициализации проги и результат каждого вносит в некий глобальный журнал событий, а уже потом другой пробегается по этому журналу и, если видит фатальный еррор, то выводит по нему данные. Он же вроде пишет события в .xml, имя которого фигурирует в сообщении об ошибке. Дальше, наверное, логично было бы разобраться с форматом этих событий, искать код их добавления в журнал и пытаться отследить источник того самого "отказано в доступе". Но перспективы были туманны, было лень, и появлялось ощущение, что так дальше нельзя и я работаю, как дилетант. Нужна система. Вспомнилось, что в юности приходилось юзать весьма полезную тулзу — API Monitor. Та версия, которая нашлась на винте, естественно, понятия не имела про 64 бит системы, но, к счастью, проект все ещё жив и развивается, обновил. Дальше запускаем, загружаем VS, материмся на антивирус, который не дал заинжектить код в запущенный процесс, достаем Монитор из карантина, отключаем антивирь, дубль два... Вуаля! Становится понятно, что вызов, который ловит access denied и не даёт VS запуститься, — это RegCreateKeyExW, пытающийся создать подключ в ветке Software\Microsoft\VisualStudio. Ну, теперь-то всё ясно... Или нет? Лезу в реестр, проверяю разрешения для этой ветки, с удивлением обнаруживаю, что они в порядке, вызов должен отрабатывать. Но в программе он падает. Как такое может быть? Чертовщина прямо. Тут следствие ещё некоторое время побродило по ложному пути, связанному с тем, перед злополучным обращением к реестру есть странный вызов ImpersonateLoggedOnUser с заведомо неверным токеном 0xffffffffffffffff. Зачем? Так и не понял. Зато в какой-то момент вернулся к вызову RegCreateKeyExW и обратил внимание на первый параметр. Раньше не приходилось видеть использование подобных API с чем-то кроме HKLM и HKCU, поэтому автоматически подумал, что использована одна из этих констант, просто Монитор почему-то не расшифровал ее название. Но нет. Как оказалось, это хэндл, который приходит из другого вызова, неведомой мне ранее RegLoadAppKeyW. Вот вроде и не новичок в WinAPI, но впервые узнал, что проги могут создавать свои приватные мини-реестры в локальных файлах, любопытно. Воистину, век живи — век учись, дураком помрёшь. В данном случае грузится файл privateregistry.user.bin в профиле юзера, в котором VS видимо хранит какие-то настройки. И, судя по всему, в процессе добавления нового языка, либо при неудачной попытке обновиться до актуальной версии инсталлер Студии по какой-то причине запорол права доступа к одному из ключей в этом файле, что и заставило VS падать при запуске. Писать чинилку прав или искать софт, работающий с локальными реестрами? Нафиг. Просто грохаю файл, запускаю Студию, вижу радостное начальное окно с предложением залогиниться и выбрать тему. Ура, затащено! Что-то из настроек наверняка потерял, но не критично. Наверное. Даже настройки шрифта сохранились. Переезд на новый ноут снова откладывается.
Что сделал бы нормальный, адекватный человек в ситуации
А что сделал я? Первым делом запустил дебагер. Почему-то была наивная уверенность в том, что место возникновения ошибки должно находиться недалеко от вывода сообщения об этой ошибке. Бряк на MessageBoxA(W) и несколько часов отладки показали, что я (внезапно!) недооценил масштаб и сложность приложения. Там сначала один метод выполняет ряд операций по инициализации проги и результат каждого вносит в некий глобальный журнал событий, а уже потом другой пробегается по этому журналу и, если видит фатальный еррор, то выводит по нему данные. Он же вроде пишет события в .xml, имя которого фигурирует в сообщении об ошибке. Дальше, наверное, логично было бы разобраться с форматом этих событий, искать код их добавления в журнал и пытаться отследить источник того самого "отказано в доступе". Но перспективы были туманны, было лень, и появлялось ощущение, что так дальше нельзя и я работаю, как дилетант. Нужна система. Вспомнилось, что в юности приходилось юзать весьма полезную тулзу — API Monitor. Та версия, которая нашлась на винте, естественно, понятия не имела про 64 бит системы, но, к счастью, проект все ещё жив и развивается, обновил. Дальше запускаем, загружаем VS, материмся на антивирус, который не дал заинжектить код в запущенный процесс, достаем Монитор из карантина, отключаем антивирь, дубль два... Вуаля! Становится понятно, что вызов, который ловит access denied и не даёт VS запуститься, — это RegCreateKeyExW, пытающийся создать подключ в ветке Software\Microsoft\VisualStudio. Ну, теперь-то всё ясно... Или нет? Лезу в реестр, проверяю разрешения для этой ветки, с удивлением обнаруживаю, что они в порядке, вызов должен отрабатывать. Но в программе он падает. Как такое может быть? Чертовщина прямо. Тут следствие ещё некоторое время побродило по ложному пути, связанному с тем, перед злополучным обращением к реестру есть странный вызов ImpersonateLoggedOnUser с заведомо неверным токеном 0xffffffffffffffff. Зачем? Так и не понял. Зато в какой-то момент вернулся к вызову RegCreateKeyExW и обратил внимание на первый параметр. Раньше не приходилось видеть использование подобных API с чем-то кроме HKLM и HKCU, поэтому автоматически подумал, что использована одна из этих констант, просто Монитор почему-то не расшифровал ее название. Но нет. Как оказалось, это хэндл, который приходит из другого вызова, неведомой мне ранее RegLoadAppKeyW. Вот вроде и не новичок в WinAPI, но впервые узнал, что проги могут создавать свои приватные мини-реестры в локальных файлах, любопытно. Воистину, век живи — век учись, дураком помрёшь. В данном случае грузится файл privateregistry.user.bin в профиле юзера, в котором VS видимо хранит какие-то настройки. И, судя по всему, в процессе добавления нового языка, либо при неудачной попытке обновиться до актуальной версии инсталлер Студии по какой-то причине запорол права доступа к одному из ключей в этом файле, что и заставило VS падать при запуске. Писать чинилку прав или искать софт, работающий с локальными реестрами? Нафиг. Просто грохаю файл, запускаю Студию, вижу радостное начальное окно с предложением залогиниться и выбрать тему. Ура, затащено! Что-то из настроек наверняка потерял, но не критично. Наверное. Даже настройки шрифта сохранились. Переезд на новый ноут снова откладывается.