Обновление Яндекс Диска привело к неработоспособности Windows и программ

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

Я уже предвкушаю завтрашние заголовки сомнительных ресурсов: «Лаборатория Касперского объявила Яндекс.Диск „забагованной хренью“».

Главное, чтобы не получилось так как у Яндекса.

Стандартная проблема. Haters gonna hate.

Минусов в карму можно получить за самый безобидный вопрос)

Количество свободной памяти диспетчер показывает верное, но именно из-за фрагментации начинаются проблемы, ибо очень часто приложения хотят относительно большие куски памяти, к примеру, для рендеринга картинок в браузере может понадобиться от нескольких сотен кБ до нескольких МБ буфер на каждую картинку, этот буфер разумеется должен быть непрерывным и явно (разработчиком софта) или косвенно (менеджером памяти) будет выделен кратно размеру страниц, помимо этого существуют явные проблемы фрагментации куч, различные последствия работы сборщиков мусора, в особенности отложенная по тем или иным причинам сборка мусора, а так же собственные менеджеры памяти в приложениях, которые тоже хотят резервировать большие страницы, и т.д.

Помимо этого полное отключение файла подкачки на системном диске приведёт к невозможности создания дампа памяти в случае BSOD, эта возможность нужна довольно редко, но обычно когда она нужна лучше что бы всё работало. Для примера можно взять ситуацию когда после обновления системы, и или дров система начинает валиться в BSOD даже в безопасном режиме — это пример довольно таки сферический и в вакууме, и лично мне так ни разу не приходилось с этим сталкиваться, но теоретически такое может быть, и вот если такое реально случится, то по простому починить систему будет уже сложнее, и придётся сначала включать файл подкачки через сторонний загрузочный диск, и только потом смотреть, что же там в дампе.

Лично я нигде Вас не минусовал, ибо задавать любые вопросы это хорошо. Однако я понимаю откуда эти минусы, да и что далеко ходить, мне, как разработчику ПО, частенько приходится разгребать дампы с badallocation, которые возникают у юзеров с отключённым своп, и это, поверьте мне очень и очень грустно, ибо это обычно падение в совершенно случайном месте, и часто совершенно не понятно чем оно вызвано, т.е. дамп приходит с малюсеньким куском памяти, даже без стека, не говоря уже о полном дампе, который крайне желателен в многопоточных приложениях, а без стека он приходит по той же причине по которой случился badallocation — не хватило памяти ибо не удалось выделить кусок памяти для снятия дампа :)… и это ещё хорошо если хоть какой то дамп приходит, а бывает, что вообще ничего не приходит, а у юзера приложение падает, и он не понимает почему. Самое обидное в таких дампах это то, что не возможно понять то ли это я балбес и где то у меня порча памяти, то ли юзер балбес и у него своп отключен. В итоге такие дампы чаще всего просто помечаются как не подходящие для анализа, но время на них тратить каждый раз приходится.

Большой p.s :): так же бытует, вполне оправданное мнение, что разработчики ОС лучше знают как именно она работает, и какие режимы для неё более оптимальные, и именно по этой причине менять какие то системные настройки без понимания, что именно за ними реально стоит явно не стоит, по этой же причине не стоит использовать различные «оптимизированные» сборки ОС, собранные не понятно кем, и не понятно по каким соображениям. Собственно данный подход обычно позволяет использовать ОС и софт годами без каких либо глюков и странностей, исключение составляют лишь особо кривые приложения и драйверы, но их очень и очень мало, и глючат они у всех :)

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