Баг в конфиге может положить целую Windows — инженер Microsoft разобрал реальный случай

Инженер Microsoft Мэтт Хэмрик опубликовал разбор ошибки, которая может вызвать утечку памяти, замедление системы и даже крах всей Windows — и все это из-за одной строчки в конфигурационном файле .NET-приложения.

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

Проблема возникает, если установить reloadOnChange: true в неподходящем месте — например, в контроллере или middleware-компоненте. В этом случае каждый вызов создает нового «наблюдателя» за файлом, и память начинает стремительно заполняться.

Что делает reloadOnChange

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

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

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

Как Microsoft нашла баг

Хэмрик обнаружил проблему, анализируя дампы памяти .NET, снятые через WinDbg и другие инструменты. Он увидел, как объект конфигурации разрастается в памяти — и каждый экземпляр привязан к новой копии FileSystemWatcher, который отслеживает изменения одного и того же файла.

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

Почему это важно

Такие баги коварны: они не приводят к ошибке сразу. Но если приложение активно, баг способен положить всю систему — и администратор потратит часы на поиски причины, не подозревая, что виноват всего один флаг в конфиге.

Инженеры Microsoft советуют использовать reloadOnChange осознанно и только там, где это действительно необходимо. Особенно в продакшене.

Разработчики против пользователей

Этот кейс — пример того, как даже маленькая ошибка в коде может превратиться в системную проблему. И это особенно актуально на фоне разговоров о производительности Windows, медленной работе старых устройств и резком росте требований к «железу».

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