Windows обновить переменные среды без перезагрузки

Обновлено: 03.07.2024

Если я изменяю или добавляю переменную среды, я должен перезапустить командную строку. Есть ли команда, которую я мог бы выполнить, чтобы сделать это без перезапуска CMD?

Вы можете захватить переменные системной среды скриптом vbs, но вам нужен сценарий bat, чтобы фактически изменить текущие переменные среды, поэтому это комбинированное решение.

Создайте файл с именем resetvars.vbs содержащий этот код, и сохраните его на пути:

Когда вы хотите обновить переменные среды, просто запустите resetvars.bat

Две основные проблемы, с которыми я столкнулся с этим решением, были

а. Я не мог найти простой способ экспортировать переменные среды из сценария vbs обратно в командную строку и

б. переменная среды PATH представляет собой конкатенацию пользователя и системных переменных PATH.

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

Я использую странный vbs + bat + временный механизм bat, чтобы обойти проблему экспорта переменных из vbs.

Примечание: этот скрипт не удаляет переменные.

Вероятно, это можно улучшить.

ADDED

Если вам нужно экспортировать среду из одного окна cmd в другой, используйте этот скрипт (позвоните на него exportvars.vbs ):

Запуск exportvars.vbs в окне вы хотите экспортировать из, а затем переключиться на окно, которое вы хотите экспортировать, и типа:

Вот что использует Chocolatey.

В окнах 7/8/10 вы можете установить Chocolatey, у которого есть script для этого встроенного.

После установки Chocolatey просто введите "refreshenv" без кавычек.

Если вы изменяете или добавляете новую переменную среды за пределы существующей открытой командной строки, вам нужно либо перезапустить командную строку, либо вручную добавить с помощью SET в существующую командную строку.

последний принятый ответ показывает частичную обработку, вручную обновляя все переменные среды в script. script обрабатывает прецедент изменения переменных среды во всем мире в "My Computer. Environment Variables", но если переменная среды изменяется в одном cmd.exe, то script не будет распространять ее на другой запущенный cmd.exe.

Я наткнулся на этот ответ, прежде чем найти более легкое решение.

Просто перезапустите explorer.exe в диспетчере задач.

Я не тестировал, но вам также может понадобиться повторно открыть командную строку.

Кредит Timo Huovinen здесь: Node не признан, хотя успешно установлен (если это помогло вам, пожалуйста, дайте этому человеку комментарий кредит).

Это работает в Windows 7: SET PATH=%PATH%;C:\CmdShortcuts

проверено путем ввода echo% PATH%, и это сработало, отлично. также устанавливаются, если вы открываете новый cmd, больше не нужно для этих отвратительных перезагрузок:)

Используйте "setx" и перезапустите приглашение cmd

Для этого задания используется инструмент командной строки с именем setx". Он для чтения и записи переменных env. Переменные сохраняются после закрытия командного окна.

It "Создает или изменяет переменные среды в пользовательской или системной среде, не требуя программирования или скриптов. Команда setx также извлекает значения ключей реестра и записывает их в текстовые файлы. "

Примечание: переменные, созданные или измененные этим инструментом, будут доступны в будущих командных окнах, но не в текущем командном окне CMD.exe. Итак, вы должны перезапустить.

Если setx отсутствует:

Или изменить реестр

Вызов этой функции сработал у меня:

Лучший метод, который я придумал, - это просто выполнить запрос реестра. Вот мой пример.

Orginal Batch вызывает новую партию:

testenvget.cmd SDROOT (или любая переменная)

Также есть другой метод, который я придумал из разных идей. См. Ниже. Это, в основном, приведет к новой переменной пути из реестра, однако это вызовет ряд проблем, связанных с тем, что запрос реестра будет давать переменные сами по себе, а значит, везде есть переменная, это не сработает, поэтому для борьбы с этой проблемой я в основном удваивают путь. Очень противно. Более предпочтительный метод: Set Path =% Path%; C:\Program Files\Software. \

Независимо от того, что это новый пакетный файл, будьте осторожны.

Это можно сделать, перезаписав таблицу окружения в пределах самого указанного процесса.

В качестве доказательства концепции я написал это примерное приложение, которое только что редактировало одну (известную) переменную среды в процессе cmd.exe:

Примечания

Этот подход также будет ограничен ограничениями безопасности. Если цель запущена на более высокой отметке или более высокой учетной записи (например, SYSTEM), у нас не будет разрешения на редактирование ее памяти.

Если вы хотите сделать это в 32-битном приложении, то жестко закодированные смещения выше будут меняться на 0x10 и 0x48 соответственно. Эти смещения можно найти, выгружая структуры _PEB и _RTL_USER_PROCESS_PARAMETERS в отладчике (например, в WinDbg dt _PEB и dt _RTL_USER_PROCESS_PARAMETERS )

Чтобы изменить концептуальную концепцию на то, что требуется OP, она просто перечислит текущие переменные системы и пользовательских окружений (например, задокументированные ответом @tsadok) и напишет всю таблицу окружения в память целевого процесса.

Изменить: размер блока среды также сохраняется в структуре _RTL_USER_PROCESS_PARAMETERS, но память выделяется в куче процесса. Поэтому из внешнего процесса у нас не было бы возможности изменять его размер и увеличивать его. Я играл с помощью VirtualAllocEx, чтобы выделить дополнительную память в целевом процессе для хранения среды, и смог установить и прочитать совершенно новую таблицу. К сожалению, любая попытка изменить среду с помощью обычных средств будет сбой и сбой, поскольку адрес больше не указывает на кучу (он сбой в RtlSizeHeap).

Переменные среды хранятся в HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Control\Session Manager\Environment.

Многие полезные env vars, такие как Path, сохраняются как REG_SZ. Существует несколько способов доступа к реестру, включая REGEDIT:

REGEDIT /E <filename> "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Environment" код >

Выход начинается с магических чисел. Поэтому, чтобы искать его с помощью команды find, ее нужно набирать и перенаправлять: type <filename> | findstr -c:\"Path\"

Итак, если вы просто хотите обновить переменную пути в текущем командном сеансе с тем, что в свойствах системы следующая партия script отлично работает:

Самый простой способ добавить переменную к пути без перезагрузки для текущего сеанса - открыть командную строку и ввести:

и нажмите enter .

чтобы проверить, загружена ли ваша переменная, введите

и нажмите enter . Однако переменная будет только частью пути до перезагрузки.

Путаница может заключаться в том, что есть несколько мест для запуска cmd. В моем случае я запустил cmd из Windows Explorer, а переменные не изменились, когда при запуске cmd из "run" (ключ Windows + r) изменена переменная окружения .

В моем случае мне просто пришлось убить процесс проводника Windows из диспетчера задач, а затем снова перезапустить его из диспетчера задач.

Как только я сделал это, у меня был доступ к новой переменной среды из cmd, которая была порождена из обозревателя Windows.

Попробуйте открыть новую командную строку в качестве администратора. Это работало для меня в Windows 10. (Я знаю, что это старый ответ, но мне пришлось поделиться этим, потому что писать VBS script просто для этого абсурдно).

Перезапуск explorer сделал это для меня, но только для новых CMD терминалов.

Терминал, на который я установил путь, мог видеть новую переменную Path уже (в Windows 7).

Я использую следующий код в своих командных скриптах:

Используя SET после SETX, можно использовать "локальную" переменную напрямую без перезапуска окна команд. И при следующем запуске будет использоваться переменная среды.

Мне понравился подход, за которым последовали шоколадные, как указано в анонимном трусовом ответе, так как это чистый пакетный подход. Однако он оставляет временный файл и некоторые временные переменные. Я сделал для себя более чистую версию.

Сделайте файл refreshEnv.bat где-нибудь на вашем PATH . Обновите среду консоли, выполнив refreshEnv .

Если это касается только одного (или нескольких) конкретных vars, которые вы хотите изменить, я думаю, что самый простой способ - это обходной путь: просто установите в своей среде И в текущем сеансе консоли

Set поместит var в ваш текущий сеанс
SetX поместит var в среду, но НЕ в ваш текущий сеанс

У меня есть эта простая партия script, чтобы сменить мой Maven с Java7 на Java8 (которые являются как env. vars) Пакетная папка находится в моем PATH var, поэтому я всегда могу позвонить ' j8 'и внутри моей консоли и в среде меня изменяет мой JAVA_HOME var:

j8.bat:

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

Сначала установите choco:

если используется cmd @"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -InputFormat None -ExecutionPolicy Bypass -Command "iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))" && SET "PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin"

Затем вы можете запустить refreshenv . Он работает как на cmd, так и на powershell.

Если вам просто нужно обновить переменные среды в Windows, запустите refreshenv из вашего терминала, чем перезагрузить компьютер.

Это было хуже: в старых версиях Windows вам пришлось выйти из системы, а затем вернуться назад, чтобы принять во внимание изменения.

Я использую эту Powershell script для добавления в переменную PATH. С небольшой настройкой он может работать и в вашем случае, я тоже верю.

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

Например, мы используем это для обеспечения возможности развертывания и настройки программного обеспечения на большом количестве машин, которые мы регулярно переустанавливаем. И я должен признать, что перезапуск командной строки во время развертывания нашего программного обеспечения был бы очень непрактичным и потребовал бы от нас найти обходные пути, которые не обязательно приятны. Давай доберемся до нашей проблемы. Мы действуем следующим образом.

1 - у нас есть пакетный скрипт, который в свою очередь вызывает скрипт powershell, подобный этому

[файл: task.cmd].

cmd > powershell.exe -executionpolicy unrestricted -File C:\path_here\refresh.ps1

2 - После этого сценарий refresh.ps1 обновляет переменные среды, используя ключи реестра (GetValueNames() и т.д.). Затем в том же скрипте powershell нам просто нужно вызвать новые переменные среды. Например, в типичном случае, если мы только что установили nodeJS ранее с помощью cmd с использованием тихих команд, после вызова функции мы можем напрямую вызвать npm для установки в том же сеансе определенных пакетов, как показано ниже.

[файл: refresh.ps1]

После завершения сценария powershell сценарий cmd выполняет другие задачи. Теперь следует иметь в виду, что после завершения задачи cmd по-прежнему не имеет доступа к новым переменным среды, даже если сценарий powershell обновил их в своем собственном сеансе. Вот почему мы выполняем все необходимые задачи в скрипте powershell, который, конечно, может вызывать те же команды, что и cmd.

я внес некоторые изменения в %PATH% переменной в реестре. Теперь я хотел бы, чтобы эти изменения применялись без необходимости заходить в систему, перезагружаться или перезагружать Explorer. Есть ли способ это сделать?

Я бы предпочел сделать это с помощью какой-то команды, которые можно поставить в конце .BAT файл, и не хотите использовать какие-либо инструменты, кроме тех, которые поставляются с ОС в новой установке. Это должно быть минимально совместимо с Windows XP SP3, и работа полностью до Windows 7 x64 и Server 2008 R2.

изменить путь пользователя или системы в свойствах системы.
запуск этого пакетного файла извлекает новые переменные пути с запросом REG.
команды FOR анализируют переменные пути из результатов REG.
текущий путь обновляется до значений реестра.
Я использую ConEmu для своих консолей, и он запускает этот пакетный файл на каждой новой консоли, чтобы обновить путь, поэтому перезагрузка не выполняется необходимый.

задание команды параметр в запусках ConEmu C:\Windows\System32\cmd.ехе с /к переключатель для запуска refreshpath.cmd выше, а затем остаются. Это обновляет путь и оставляет консоль открытой.

C:\Windows\System32\cmd.exe /k refreshpath.cmd

Если вы пытаетесь использовать новое значение переменной path из командной оболочки Windows, все, что вам нужно сделать, это закрыть окно командной оболочки и открыть новое. Новая командная оболочка загрузит обновленную переменную path.

поэтому я думаю, что ответ на ваш первоначальный вопрос зависит от того, где именно вы пытаетесь увидеть, как изменение вступит в силу. Есть что-то, что не работает для вас?

самый простой способ добавить переменную в путь без перезагрузки-открыть командную строку и ввести: PATH=(VARIABLE);%path% и нажать enter. Чтобы проверить, загружена ли переменная, введите PATH и нажмите enter.

измените переменную PATH из пользовательского интерфейса в переменных среды.
добавьте новую переменную окружения, назовите ее случайной. Может быть, что-то вроде CHANGE_TO_UPDATE и поместить в него случайное значение вроде x.
Не забудьте перезапустить cmd.exe или любая программа, которая должна видеть новую переменную path.

это на самом деле вызовет настройки для обновления при запуске нового приложения.

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

Допустим, у вас есть рабочий сервер, на котором размещены различные приложения, а для запуска нового приложения требуется определенная переменная среды. Вы не хотите перезагружать его, когда пользователи подключены к другим вашим приложениям. Какой у вас есть выбор? Мне не нравится опция «ждать, пока наступит хорошее время для перезагрузки». Должен быть лучший способ. Что мне не хватает?

У меня была такая же проблема. Я где-то читал, что уничтожение процесса explorer.exe приведет к обновлению переменных, и это сработало. Тогда мне просто нужно было запустить проводник из диспетчера задач. Вы должны закрыть командную строку и снова открыть ее, чтобы обновить переменные пути. Переменные загружаются при запуске cmd.

Я не могу сказать из вашего описания проблемы, какая конкретно у вас проблема с этим. Можете ли вы рассказать нам больше о конкретном сценарии, который не работает?

Ладно, наверное, я видел такое поведение на работающем сервисе или что-то в этом роде. Я добавил новую переменную среды, используя метод, описанный выше. Затем я смог увидеть значение после открытия новой командной строки и использования команды "echo% <myvar>%. Спасибо вам обоим за ваши ответы. Для пользователей PowerShell этот фрагмент может быть полезен Если вы используете cmd, вы должны перезапустить его, если измените переменную env

В командной строке введите: runas /user:yourusername@yourdomain cmd
Откроется новое приглашение cmd, затем введите: taskkill /f /im explorer.exe
Затем введите: explorer.exe

Теперь, закрыв все командные строки, вы увидите, что PATH переменная действительно обновлена.

Все командные строки должны быть закрыты. Снова откройте новую командную строку, введите путь, и вы увидите новые данные.

Это сработало для меня. Я думаю, проблема в том, что если вы запускаете cmd через проводник (чтобы избавить вас от необходимости вводить длинные пути), то проводник никогда не закрывается, даже если вы закрываете все окна проводника. Спасибо за решение :) Работал на меня. Вы также можете просто использовать диспетчер задач, чтобы убить задачи проводника и перезапустить его («Файл»> «Запустить новую задачу»). Гм. Пожалуйста, не убивайте Windows Explorer, если один из его процессов не завис. Вместо этого откройте диалоговое окно выключения и отмените его, удерживая ctrl+alt+shift . Это будет чисто выйти из Windows Explorer. В Vista + диалоговое окно выключения труднее найти (но все еще присутствует, по крайней мере, через 7 (не уверены около 8 и 10)), поэтому существует второй метод. Ctrl + Shift + щелчок правой кнопкой мыши в пустой части меню «Пуск» и выберите «Проводник выхода». В 8 опция выхода та же, но вы используете панель задач, а не меню «Пуск». +1 Это работает как очарование в Windows 7. К вашему сведению, я просто использовал CTRL + ALT + SHIFT, и из диспетчера задач Windows я убил весь процесс explorer.exe, а затем снова запустил его, нажав кнопку « Новая задача» .

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

Эта проблема затрагивает ВСЕ УСЛУГИ, даже перезапущенная служба не увидит новые переменные среды. Вы уверены, что это не из-за совместного использования процесса svchost?

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

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

Часть о переменных окружения, сбрасывающих к предыдущим значениям после перезагрузки командной строки, является точно тем, что я испытал в Windows Server 2008.

В статье говорится:

Как-то раз мне потребовалось отсканировать документ, но при попытке открыть интерфейс сканера появилась ошибка:

Согласно одному из советов на официальном сайте было предложено добавить папку с библиотеками сканера в переменную PATH, что я и сделал по своей же инструкции:

Скопировал в буфер обмена нужный путь (у меня это «C:\Windows\twain_32\CNQL25», без кавычек)
Открыл оснастку «Система» быстрой комбинацией Win + R
Нажал слева «Дополнительные параметры» => «Переменные среды»
В группе «Системные переменные» нашел переменную PATH, «Изменить»
Поставил курсор в конец строки с полем «Значение переменной» и убедился, что в конце строки есть знак «точка с запятой»
И нажал «Вставить из буфера» по ПКМ.

Но ничего не вставилось , а в колонках раздался радостный звук «Дзыньк» =)))

Первая мысль – в буфер обмена ничего не скопировалось (хотя в этом случае пункт «Вставить» должен был быть серым).
Ну да ладно, гадать не буду, и решил просто вручную набрать путь с клавиатуры.
Но не тут-то было.
В ответ всё те же радостные звуки «Дзыньк-дзыньк».

Неисправна клавиатура?

Да нет же, проверил в блокноте, всё нормально набирается.
Что же делать?

1. Способ дилетанта

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

PATH – это особая переменная, которая собирается из двух параметров PATH в ключах реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
HKEY_CURRENT_USER\Environment (по-умолчанию, здесь параметра PATH нет).

Учитывая, что у меня на полочке лежит недописанная статья о переменных окружения, было нетрудно «вспомнить» этот путь, перейти туда, открыв «Редактор реестра» (Win + R, regedit), и отредактировать значение параметра PATH.

OK, перезагрузка, и ошибка со сканером пропала.

Отступление от темы статьи:

… хотя появилась другая ошибка, что якобы TWAIN используется другим устройством.
Дальше была переустановка драйвера сканера с удалением уст-ва через «Панель управления». Но это тоже не помогло. В общем, в итоге я всё-таки отсканировал документ, подцепив USB-сканер через виртуальную машину с Windows XP непосредственно в момент установки драйвера (кстати, виртуалка с Win7, почему-то отказалась его увидеть).

2. Способ рядового исследователя

И вот, наконец, появилось время разобраться, что же происходит с PATH.

Новая мысль – заблокированы права (политики? список контроля доступа (DACL) ? ).

О политиках я не слышал, чтобы была такая, контролирующая PATH (но не исключаю).
А на счёт списка прав – они назначаются только на весь ключ реестра, а не на конкретный параметр (в нашем случае переменную). Т.е., если заблокирована PATH, то тоже самое должно происходить и со всеми соседними переменными.

Эксперимент.
Возьму первую попавшуюся – переменную «OS».
Пробую – и бац, в оснастке «Переменные среды» её значение легко поменялось.

Так-то. Давайте подойдём с другой стороны:

а что на счёт консоли?

Командная строка CMD (Win + R, cmd) позволяет также менять значение PATH, но это работает только в границах сессии консоли, а не на всю систему.

Там даже есть отдельная внутренняя команда Path. Но мы обойдёмся без неё.
Добавим для теста наш путь командой:

Получили «Отказано в доступе».
Любопытно.

Всё таки: проблемы в правах?

А что если просто распечатать содержимое?

Вот так новость. Я её даже не могу распечатать!

Попробуем с правами администратора?

Именем святого Админа, запускаем командную строку:

Нет, всё же, не везёт нам.

Может дело просто в каких-то спецсимволах в путях? Ком. строка очень не любит всякие птички ^, скобки и прочее.

Давайте заключим содержимое в кавычки:

И даже работает присвоение:

Хорошо. Но в чём именно проблема?
Я скопировал в блокнот всё значение (взял из реестра).
И методом половинного деления начал подставлять эту строку в echo.

В итоге выяснилось, что где-то в средину пути попала такая штука:

Символ перенаправления строки в файл >.
В итоге, вместо того, чтобы распечатать строку на экран консоли, она пыталась вывести её в файл C:\Windows\System32;C:\Windows;C:\Wi… не являющийся корректным именем. Из-за чего и возникала ошибка «Отказано в доступе»

А что же на счёт системы?
> - это недопустимый символ для пути. Получается, всё это время система «глючила» из-за него?

Открыв редактор реестра, я удалил знак > из параметра PATH.
(заодно заметив, что у меня 2 раза повторяются все пути, но пока решил это не трогать).

ОК, ещё раз захожу в оснастку «Система» в «переменные окружения», пытаюсь изменить значение PATH, и … снова не получается.
Но тут всё понятно:

Так что мы просто перезапустим процесс explorer, который отвечает за загрузку окон оснасток (напомню, это можно сделать через Ctrl + Shift + ПКМ по окну в меню «Пуск»).

Или, что более надёжно, перезагрузим всю систему.

Вот уже появились ярлычки. Захожу, проверяю, и …

Каково было удивление, но ничего не сработало. Символы опять не печатаются в поле «Значение переменной». ))))

Но не отчаиваемся. Остался один очевидный факт:
1) Два раза дублируются пути
2) Строка с содержимым Path какая-то уж слишком длинная
3) Заметил, что в поле «Значение переменной» хоть и нельзя печатать, но можно удалять символы.

Итак, ограничение по длине?

Но, какого рода лимит?
Может, предел для длины значения параметра реестра?
Открываем базу знаний Micosoft: Registry Elements Size Limits.

Value name
16,383 characters
Windows 2000: 260 ANSI characters or 16,383 Unicode characters.

А наша строка = 2271 символов.
Пишут, что в Win2k был жесткий лимит – в 260, но это только для ANSI-версий API-функций, а внутренне – строки хранятся в реестре все равно в Unicode. Точнее, в смешанном виде ANSI + Unicode (механизм оптимизации, детальнее о котором писал Руссинович в «Windows Internals»). Да и у меня под руками Windows 7, так что не вариант.

Эксперимент.
Поскольку оснастка даёт нам право удалять символы, а давайте так и сделаем.
Будем удалять их до тех пор, пока текстовое поле не позволит нам вводить новые символы.

И… ура, сработало

После нескольких десятков удалённых, нам позволили наконец-то вводить новые символы (не пришлось даже нажимать кнопку «ОК»).

Давайте же замерим, сколько получилось в итоге максимальное число символов.

Мой любимый AkelPad показывает что их – 2047.

Вот как. И что же за магическое число 2047 ?

Спросим у великого гуру – Google: «Path limit 2047»

Первая же ссылка ведёт на довольно любопытную статью от Karthiyayini C. (из Intel): Limitation to the length of the System PATH variable.

В ней даётся таблица с симптомами «переполнения» переменной PATH, когда её длина >= 2048 символов:

Решение проблемы даётся тоже весьма любопытное: перезагрузить систему, и она сама обрежет переменную до максимально допустимого размера.

Итог и решение проблемы.
Для однозначного решения проблемы остаётся второй вариант (также предложенный и в статье от Intel) – это обрезать значение самому.

После удаления лишних путей в строке PATH и приведения её длины до приемлемых размеров (меньше 2048 символов) я записал это значение через «Редактор реестра» в параметр PATH ключа HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment.

Проблема решена.
А сегодня мой сканер работает нормально даже в моей основной системе. Уж не знаю, связана ли его проблема была с PATH или нет. Но лично я доволен.
А моя статья надеюсь, ещё принесёт кому-то пользу, как и увлекательный рассказ о процессе поиска виновника, который может сподвигнуть вас на использование похожих методов при поиске и решении других видов неисправностей.

Читайте также: