Windows работает как две реестры?

Question

У нас есть программное обеспечение, которое сохраняет информацию о своем подключении в реестре Windows, в разделе HKLM\Software . Это только 32-битное приложение, а не 64-битное, и мы хорошо знаем о различных местах для этого (WOW6432Node). Мы на 150% уверены, что мы читаем и пишем одни и те же записи реестра - нашему программному обеспечению более 20 лет.

В прошлом месяце 3 компьютера, два из которых Windows 7 и третий Windows 10, работали очень странно. Единственный способ, которым мы можем это описать, это то, что реестр Windows дублирован! Мы записываем информацию о подключении в реестр для нашего приложения для подключения к серверу. Но он читает старые записи, которые мы изменили давным-давно!

Кажется, если мы запустим приложение "Как администратор", то они захотят играть красиво. Хотя вошедший в систему пользователь является локальным администратором ПК. Например, мы открываем Regedit и меняем одну из этих записей. Запустите наше приложение, и оно считывает старые записи до того, как оно было изменено, но затем мы запускаем приложение от имени администратора, и вдруг оно получает правильные записи.

Это известная проблема? Что тут происходит? Это какое-то обновление Windows сломало это? Что я могу сделать, чтобы это исправить?

Answer 1

Как программист, я часто сталкивался с этой ситуацией; компания будет более 20 лет использовать приложение, которое было написано для более старой версии Windows, а затем будет вынуждена выполнить обновление, только чтобы выяснить, что из-за обновлений безопасности Windows или самой версии Windows их программное обеспечение устарело. а не на практике.

Вероятно, здесь происходит то, что ваше приложение сталкивается с проблемой групповой политики. Групповая политика может использоваться для изменения реестра или поведения реестра в зависимости от того, какой пользователь вошел в систему. Я бы посмотрел на причину вашей проблемы, хотя, если вы добавите в реестр то, что вы делаете, чтобы ваше приложение работало, может появиться новая информация о том, почему это происходит.

Возникает проблема, заключающаяся в том, что с учетом того, что Windows работает таким образом, она может поставить разработчиков в зависимость от сетевой ИТ-группы, поскольку они обычно управляют групповыми политиками. Большинство современных разработчиков стараются держаться подальше от работы ОС сейчас при разработке приложений и хранят информацию о конфигурации либо в базах данных, либо в локальных конфигурационных файлах. Хотя работа с групповыми политиками может привести к краткосрочному исправлению, вполне вероятно, что реальное решение состоит в том, чтобы изменить ваше программное решение таким образом, чтобы все, что он делает в реестре, теперь обрабатывалось самостоятельно. Любой, кто скажет «нет, мы не должны обновлять наше 20-летнее программное обеспечение, потому что оно будет стоить слишком дорого», просто пинает банку, пока не наступит день, когда незначительное изменение ИТ полностью и навсегда сломает программное обеспечение и будет стоить организации намного больше

Answer 2

Проблема может быть связана с виртуализацией реестра.

Реестр Windows перенаправляет записи в HKLM из программного обеспечения без прав администратора в другое, специфичное для пользователя место в реестре. Посмотрите HKEY_USERS\<User-SID>_Classes\VirtualStore

С сайта Microsoft MSDN Реализация реестра

До Windows Vista приложения обычно запускались администраторами. В результате приложения могут свободно обращаться к системным файлам и разделам реестра. Если бы эти приложения выполнялись обычным пользователем, они не работали бы из-за недостаточных прав доступа. Windows Vista и более поздние версии Windows улучшают совместимость приложений для этих приложений, автоматически перенаправляя эти операции. Например, операции с реестром в глобальном хранилище (HKEY_LOCAL_MACHINE\Software) перенаправляются в местоположение пользователя в профиле пользователя, называемом виртуальным хранилищем (HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software).

Answer 3

Поскольку я пока не могу комментировать свою репутацию, позвольте мне перечислить некоторые предложения по устранению неполадок здесь, хотя они не являются настоящими "ответами":

• Запустите вашу программу после запуска ProcMon (Process Monitor из SysInternals). Вы можете установить фильтр, включающий только имя вашей программы (или PID), и он может дать вам некоторые идеи, откуда программа читает, и / или если что-то не получается в процессе.
• Еще один инструмент sysinternals Process Explorer (или Handle) также может дать вам путь к реестру (если вы держите ключ "открытым").
• Есть ли вероятность, что у вашей программы есть какая-то логика, что она возвращается к предыдущему значению (хранящемуся на диске / в файле конфигурации и т.д.), Когда не удается прочитать из реестра? В противном случае странно, что в конечном итоге вы получаете не резервное значение по умолчанию, а значение, записанное в реестр в какой-то момент.

Answer 4

Я попросил автора использовать regedit для поиска старых данных, чтобы найти, где в реестре они скрываются. Ответ был таков: старые данные больше не существуют в реестре, но используются программой.

Ввиду этого, единственное объяснение, которое я могу придумать для программы, "читающей" старые значения, которых больше нет в реестре, состоит в том, что она вообще не читает их. Вопрос об оптическом обмане.

Я считаю, что программа должна кэшировать значения, которые она читает, и использует свои последние хорошие значения, когда она не может прочитать новые значения из реестра. (Или, может быть, он имеет некоторые встроенные значения по умолчанию для них.)

Проблема должна быть вопросом разрешений. Это объясняет, почему, когда он запускается от имени администратора, ему удается прочитать новые значения из реестра, поскольку с разрешениями администратора его нельзя заблокировать.

Я предлагаю вам использовать regedit и Explorer для сравнения прав доступа к ключу реестра с файлом .exe программы. Вы можете использовать regedit, чтобы добавить учетную запись, под которой запускается программа с разрешением на чтение, к соответствующему ключу.