Недостаточно памяти для выполнения программы visual studio

Обновлено: 07.07.2024

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

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

Для профилирования выделения памяти мы будем использовать два профилировщика - вездесущий профилировщик Visual Studio, поддерживающий режим профилирования выделения памяти, и профилировщик CLR Profiler - самостоятельный и бесплатный инструмент. К сожалению, оба инструмента часто оказывают значительное влияние на производительность приложений, интенсивно использующих динамическую память, потому что для каждой операции выделения памяти профилировщик выполняет последовательность действий по сохранению информации для последующего составления отчетов. Тем не менее, результаты могут оказаться настолько ценными, что даже 100-кратное замедление при профилировании можно потерпеть.

Профилировщик выделения памяти Visual Studio

Профилировщик Visual Studio способен собирать информацию об операциях выделения памяти и жизненном цикле объектов (которые освобождаются сборщиком мусора) в обоих режимах, дискретном и инструментированном. В дискретном режиме профилировщик собирает информацию о выделении памяти в приложении в целом. В инструментированном режиме информация собирается только из инструментированных модулей.

В представлении Functions для каждого метода будет указано количество объектов и количество байтов памяти, выделенных методом (как обычно, включительные и исключительные значения). В представлении Function Details (Сведения о функции) будет представлена информация о вызывающих и вызываемых функциях, а также указаны строки кода с объемами выделенной ими памяти в поле слева:

Но самая интересная информация содержится в представлении Allocation (Выделение), показывающем, какие ветви в стеке вызовов выделили памяти больше всего:

Позже мы узнаем, насколько важно отказаться от использования временных объектов, и обсудим феномен «кризиса среднего возраста» объектов, оказывающего существенное влияние на производительность, который проявляется в способности объектов переживать несколько циклов сборки мусора. Идентифицировать наличие этого явления в приложении можно с помощью представления Object Lifetime (Жизненный цикл объектов), сообщающем, в каком поколении объекты были утилизированы. Это представление поможет увидеть, имеются ли объекты, пережившие слишком много циклов сборки мусора. На рисунке ниже можно видеть, что все объекты строк, созданные приложением (и занимающие более 1 Гбайта памяти!) были утилизированы в нулевом поколении, а это означает, что ни одному из них не удалось прожить дольше одного цикла сборки мусора:

Хотя отчеты о выделении памяти, генерируемые профилировщиком Visual Studio, отличаются богатством информации, в них все же имеются некоторые недостатки. Например, трассировка стека вызовов с целью сгруппировать операции выделения памяти по типам объектов занимает достаточно много времени, если выделение памяти производится во множестве разных мест (что всегда верно для строк и массивов байтов). Профилировщик CLR Profiler поддерживает несколько дополнительных особенностей, делающих его ценной альтернативой профилировщику Visual Studio.

CLR Profiler

Профилировщик CLR Profiler - это отдельный инструмент профилирования, не требующий установки и занимающий менее 1 Мбайта дискового пространства. Как дополнительное преимущество, он распространяется с исходными текстами, которые наверняка заинтересуют тех, кто пожелает заняться созданием собственных инструментов, использующих CLR Profiling API. Он способен подключаться к выполняющимся процессам (если используется версия CLR не ниже 4.0) или запускать выполняемые файлы, и регистрировать все операции выделения памяти и события сборки мусора.

Пользоваться профилировщиком CLR Profiler очень просто - запустите профилировщик, щелкните на кнопке Start Application (Запустить приложение), выберите приложение для профилирования и дождитесь появления отчета - богатство информации для кого-то может оказаться ошеломляющим. Мы рассмотрим здесь некоторые отчеты профилировщика, а полное руководство вы найдете в документе CLRProfiler.doc, входящем в состав загружаемого пакета. Как обычно, для экспериментов с профилировщиком вы можете использовать пример приложения JackCompiler.exe или свое приложение.

На рисунке ниже показан главный отчет, появляющийся после завершения профилируемого приложения. Он содержит основные сведения, касающиеся выделения памяти и сборки мусора. Далее из этого отчета можно пойти в нескольких направлениях. Мы сконцентрируемся на исследовании источников выделения памяти, чтобы понять, в каком месте приложения создается больше всего объектов (этот отчет напоминает представление Allocation профилировщика Visual Studio). Мы могли бы заняться исследованием сборки мусора, чтобы узнать, какие объекты утилизируются. Наконец, можно было бы исследовать содержимое динамической памяти, чтобы получить представление о ее распределении.

Щелчок на кнопке Histogram (Гистограмма) рядом с полем Allocated bytes (Выделено байтов) или Final heap bytes (Конечный объем кучи в байтах) выведет гистограмму по типам объектов, сгруппированных по размерам. Эта гистограммы можно использовать для выявления больших и малых объектов, а также объектов, создаваемых чаще других. На рисунке ниже показана гистограмма для всех объектов, создаваемых нашим примером приложения:

Каждый столбик представляет объекты определенного размера. Легенда справа содержит общее число созданных экземпляров каждого типа и объем выделенной памяти в байтах.

Щелчок на кнопке Allocation Graph (График выделения) откроет отчет о выделении памяти в дереве стека вызовов для всех объектов в приложении. Информация в этом отчете сгруппирована так, чтобы легко можно было перейти от методов, выделивших больше всего памяти, к отдельным типам объектов и посмотреть, какие методы создали больше всего экземпляров этих типов. На рисунке ниже показана малая часть графика выделения памяти, начиная от метода Parser.ParseStatement(), выделившего (включительно) 372 Мбайт памяти и до различных методов, вызываемых им. (Кроме того, в остальных отчетах профилировщика CLR Profiler присутствует пункт контекстного меню Show who's allocated (Показать, для кого выделена память), открывающий отчет с графиком выделения памяти для подмножества объектов приложения.)

Здесь показаны только методы, информация о фактических типах объектов находится на графике правее.

Щелчок на кнопке Objects by Address (Объекты по адресу) отобразит области управляемой динамической памяти в виде слоев; чем ниже слой, тем он старше. Подобно археологу вы можете погружаться в более глубокие слои и выяснять, какие объекты занимают память в вашем приложении. Этот отчет можно также использовать для диагностики фрагментации динамической памяти:

Метки слева - это адреса, метки «gen 0» и «gen 1» - это подразделы динамической памяти.

Наконец, щелчок на кнопке Time Line (График времени) в разделе Garbage Collection Statistics (Статистика сборки мусора) откроет отчет с информацией об отдельных циклах сборки мусора и их влиянии на динамическую память приложения:

Отметки на нижней оси представляют отдельные циклы сборки мусора, а в области графика изображается состояние управляемой динамической памяти. После сборки мусора объем используемой памяти резко уменьшается, а затем постепенно возрастает, до следующего цикла. В данном случае объем используемой памяти (после сборки мусора) остается постоянным, из чего следует, что в этом приложении отсутствуют утечки памяти.

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

Графики и гистограммы выделения памяти - весьма полезные инструменты анализа, но иногда важнее бывает выявить ссылки между объектами, а не объемы выделяемой памяти в разных методах. Например, когда в приложении обнаруживаются утечки управляемой памяти, очень полезно пройтись по динамической памяти, чтобы найти категории объектов, занимающие наибольшие объемы памяти и узнать, какие объекты на них ссылаются, мешая сборщику мусора утилизировать их. Пока профилируемое приложение выполняется, щелкните на кнопке Show Heap now (Показать кучу сейчас), чтобы сгенерировать дамп динамической памяти для последующего исследования с целью классификации ссылок между объектами.

На рисунке ниже показан отчет профилировщика сразу с тремя дампами динамической памяти, расположенными друг над другом, показывающий увеличение количества объектов типа byte[], удерживаемых очередью объектов, готовых к завершению (freachable queue), из-за наличия ссылок на них в объектах Employee и Schedule:

Ha рисунке ниже показаны результаты выбора пункта Show New Objects (Показать новые объекты) контекстного меню, чтобы оставить в отчете только объекты, созданные в период времени между сохранением второго и третьего дампов:

На этом графике видно, что источником утечки памяти является цепочка ссылок из очереди объектов, готовых к завершению.

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

Коммерческие профилировщики памяти

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

Профилировщик памяти ANTS

Профилировщик ANTS Memory Profiler компании RedGate специализируется на анализе срезов динамической памяти. Ниже подробно описывается процесс использования ANTS Memory Profiler для диагностики утечек памяти. Если у вас есть желание самим повторить описываемые действия, загрузите пробную 14-дневную версию ANTS Memory Profiler, которую можно найти по адресу: ANTS Memory Profiler, и используйте ее для профилирования собственного приложения. Описание и скриншоты, представленные ниже, относятся к версии ANTS Memory Profiler 7.3, которая была последней на момент написания данных строк.

Следуя за экспериментом, описываемым ниже, вы можете использовать пример приложения FileExplorer.exe из папки с исходниками. Это приложение имитирует утечку памяти, выполняя обход дерева каталогов и не освобождая объекты с информацией о непустых каталогах.

Запустите приложение из профилировщика. (Подобно профилировщику CLR Profiler, ANTS поддерживает возможность подключения к выполняющимся процессам, начиная с версии CLR 4.0.)

По завершении инициализации приложения щелкните на кнопке Take Memory Snapshot (Сделать снимок памяти). Этот снимок будет служить основой для последующих исследований.

Накопив утечки памяти, сделайте еще один снимок динамической памяти.

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

Выберите определенный тип и щелкните на кнопке Instance Categorizer (Классификатор экземпляров), чтобы понять, какие ссылки удерживают в памяти объекты подозреваемого в утечках типа. (На этом этапе исследуются ссылки между типами - экземпляры типа A, ссылающиеся на экземпляры типа B, будут сгруппированы по типу.)

Исследуйте отдельные экземпляры подозреваемых в утечках типов, щелкнув на кнопке Instance List (Список экземпляров). Выберите несколько наиболее представительных экземпляров и щелкните на кнопке Instance Retention Graph (График зависимостей экземпляров), чтобы посмотреть, почему они удерживаются в памяти. (На этом этапе исследуются ссылки между отдельными объектами, и здесь можно выяснить причину, мешающую сборщику мусора утилизировать конкретные объекты.)

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

К концу процесса анализа у вас должно сложиться четкое представление, почему самые тяжеловесные объекты в вашем приложении не утилизируются сборщиком мусора. Существует множество причин, вызывающих утечки памяти, и их выявление проблемных объектов из миллионов имеющихся - это целое искусство.

На рисунке ниже показан пример сравнения двух снимков динамической памяти. Основные утечки памяти (в байтах) связаны с объектами string.

Детальный осмотр типа string после щелчка на кнопке Instance Categorizer (Классификатор экземпляров) наводит на мысль, что некоторое событие создает экземпляры FileInformation в памяти, которые в свою очередь хранят ссылки па объекты byte[]:

Как видно из рисунка, строки удерживаются в памяти массивами строк, которые сами удерживаются экземплярами типа FileInformation, которые в свою очередь удерживаются событием (через делегаты System.EventHandler).

Более детальное исследование конкретных экземпляров в представлении, выводимом после щелчка на кнопке Instance Retention Graph (График зависимостей экземпляров) в результате указывает, что источником утечек является статическое событие FileInformation.FileInformationNeedsRefresh:

В пятом столбце списка указано число хранящихся в памяти экземпляров, а в седьмом - количество байтов, занимаемых ими. Основной объем памяти занимают объекты string, информация о которых скрыта здесь за всплывающей подсказкой.

Недостаточно памяти для завершения этой операции

Если я перезапущу Visual Studio, все заработает.

Есть ли способ этого избежать? Есть ли лучший способ упаковать видео в установщик?

Обычно это происходит, когда процессу сборки требуется много оперативной памяти, и он не может ее получить. Поскольку перезапуск Visual Studio устраняет проблему, скорее всего, это также ваш случай.

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

Я опаздываю с ответом, но может быть полезен другим. В моем случае простой перезапуск Visual Studio решает проблему.

Я исправляю эту проблему, удаляя или отключив (исключив) файлы * .rpt, которые имеют большой размер; и я оптимизировал свои отчеты!

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

Для Visual Studio вы можете попробовать сделать следующее:

Закройте все экземпляры Visual Studio.
Откройте инструмент разработчика Visual Studio в режиме администратора .
Перейдите к:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE .
Введите следующее:
editbin /LARGEADDRESSAWARE devenv.exe .
Также стоит перезагрузить компьютер.

Надеюсь это поможет )

В моем случае сервер, на котором я выполнял код, не мог обрабатывать мой распараллеленный код.

Обычно я запускаю такую настройку, как следующая

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

Возможно, я опоздаю с ответом, но для справки в будущем вы можете проверить настройки файла дампа Windows (и, вероятно, установить для него значение «Нет»).

В моем случае на диске C осталось очень мало памяти. Я удалил несколько элементов с диска C и попробовал снова. Это сработало.

Очистка и восстановление решения помогли мне

140 МБ), и я не мог скомпилировать решение, потому что я получал

Недостаточно памяти для завершения этой операции

Ошибка в моем выводе сборки.

Мой ответ основан на этом ответе.

Решение 1. Установите переключатель /3GB Boot.ini

Виртуальное адресное пространство процессов и приложений по-прежнему ограничено 2 ГБ, если в файле Boot.ini не используется переключатель /3GB .

Переключатель /3GB выделяет 3 ГБ виртуального адресного пространства для приложения, которое использует IMAGE_FILE_LARGE_ADDRESS_AWARE в заголовке процесса. Этот переключатель позволяет приложениям адресовать 1 ГБ дополнительного виртуального адресного пространства свыше 2 ГБ.

Виртуальное адресное пространство процессов и приложений по-прежнему ограничено 2 ГБ, если только переключатель /3GB не используется в Boot.ini file . В следующем примере показано, как добавить параметр / 3GB в файл Boot.ini , чтобы включить настройку памяти приложения:

Обратите внимание: « . » в предыдущем примере - это программное имя операционной системы.

В Windows XP файл Boot.ini можно изменить, перейдя в

Свойства системы → Дополнительно → Запуск и восстановление → Настройки → Запуск системы → Изменить

На странице переключателя /3GB в MSDN написано:

В 32-разрядных версиях Windows параметр /3GB включает 4 GT RAM Tuning, функцию, которая увеличивает виртуальное адресное пространство пользовательского режима до 3 ГБ и ограничивает компоненты режима ядра оставшимся 1 ГБ.

Параметр /3GB поддерживается в Windows Server 2003, Windows XP и Windows 2000. В Windows Vista и более поздних версиях Windows используйте элемент IncreaseUserVA в BCDEdit .

После перезапуска машины настройки вступят в силу.

Решение 2. Сообщите devenv.exe о большом адресе:

Откройте командную строку Visual Studio (или командную строку разработчика, в зависимости от версии Visual Studio).

Введите и выполните следующую командную строку:

где - это путь к devenv.exe (вы можете найти его, перейдя в свойства ярлыка Visual Studio).

Это позволит devenv.exe получить доступ к 3 ГБ памяти вместо 2 ГБ.

Проблема

В моем случае проблема заключалась в тестовом проекте, содержащем очень большой (1,5 ГБ) тестовый файл в качестве встроенного ресурса . У меня на компьютере было 16 ГБ ОЗУ, из которых 8 ГБ было свободно, когда это произошло, поэтому проблема не была в ОЗУ.

Возможно, мы достигли ограничения в 2 ГБ, которое среда CLR имеет для любого отдельного объекта . Не углубляясь в то, что делает MSBuild под капотом, я могу только предположить, что во время компиляции встроенный ресурс загружается в граф объектов, который достигает этого предела.

Решение

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

Мы исправили ошибку, переместив файл в сеть (точно так же, как он будет доступен валидатору в производственной среде) и отметив тест как интеграционный, а не как модульный. В конце концов, разве модульные тесты не должны выполняться быстро?

при запуске приложения или при сохранении выдает ошибку, что "недостаточно памяти для продолжения выполнения программы". что делать в таком случае? у меня много картинок в приложении, может быть из за этого?
полностью папка с приложением весит 132 Мб, а конкретно программа (bin\debug) весит 30 Мб

Простой 2 комментария

Диспетчер задач врёт, у Вас ещё меньше памяти. Свопа осталось 62 мб, то есть если программа под распаковку картинки просит больше, то случится фейл, а языки с gc память резервируют крупными блоками. Картинки жрут чуть больше чем 4 байта на пиксель, гифки тоже для каждого кадра, тут уж сами считайте сколько это памяти. Что делать? Правильный вариант раскошелится на память, цена вопроса на али около 1500р. Неправильный, затянуть пояс потуже. Увеличить своп, перейти на 32-битную винду, грохнуть дискорд и другие прожорливые приложения и ненужные службы. В крайнем случае кодить в легковесном редакторе, а отлаживать по старинке, выводом информации в лог.

KamAKAM, Скриншот части кода не изменит мой ответ. Могу лишь добавить, что Visible никак не влияет на прожорливость классов.

none7, в основном при открытии класса "персы" приложение начинает занимать выше гб оперативки, в целом становится занято больше 70% памяти оперативки
может как то код в другое место пихнуть, или что то подобное сделать? я просто не совсем еще в этом шарю

KamAKAM, В WinForms всё самое прожорливое прячется в InitializeComponent(). Если у Вас там загружается куча изображений, то видимо это действительно они сжирают память. Спасти ситуацию может отложенная загрузка(в момент их отображения) и немедленная выгрузка и масштабирование изображений, если на экране они отображаются уменьшенными. То есть при создании класса нельзя допустить бесконтрольное создания кучи классов Image.
В принципе есть исходники и можно попробовать закешировать изображения в виде массива точек и отображать их в память через file mapping.

В Windows 10, 8 и Windows 7 пользователи могут столкнуться с ошибкой Недостаточно системных ресурсов для завершения операции — при запуске какой-то программы или игры, а также во время её работы. При этом такое может происходить и на достаточно мощных компьютерах со значительным объемом памяти и без видимых чрезмерных нагрузок в диспетчере устройств.

Чаще всего ошибка о недостаточности ресурсов бывает вызвана сравнительно простыми основными вещами и исправляется легко, для начала поговорим именно о них.

Если ошибка появляется сразу при запуске программы или игры (особенно сомнительного происхождения) — дело может быть в вашем антивирусе, который блокирует выполнение этой программы. Если вы уверены в том, что она безопасна — добавьте её в исключения антивируса или временно отключите его.
Если на вашем компьютере отключен файл подкачки (даже если установлено много RAM) или на системном разделе диска мало свободного места (2-3 Гб = мало), это может вызывать ошибку. Попробуйте включить файл подкачки, при этом использовать его размер, автоматически определяемый системой (см. Файл подкачки Windows), и позаботиться о достаточном количестве свободного места).
В некоторых случаях причина — действительно в недостаточности ресурсов компьютера для работы программы (изучите минимальные системные требования, особенно если это игра наподобие PUBG) или в том, что они заняты другими фоновыми процессами (здесь можно проверить запуск той же программы в режиме чистой загрузки Windows 10, и если там ошибка не проявляется — для начала почистить автозагрузку). Иногда может быть, что в целом для программы ресурсов хватает, но для некоторых тяжелых операций — нет (бывает при работе с большими таблицами в Excel).

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

Дополнительные методы исправления ошибки

Если ни один из способов, приведенных выше, не помог и не подошел к вашей конкретной ситуации — далее более сложные варианты.

32-бит Windows

Существует ещё один частый фактор, вызывающий ошибку «Недостаточно системных ресурсов для завершения операции» в Windows 10, 8 и Windows 7 — ошибка может появляться, если на вашем компьютере установлена 32-бит (x86) версия системы. См. как узнать, 32-бит или 64-бит система установлена на компьютере.

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

Решение одно — установить Windows 10 x64 вместо 32-битной версии, о том, как это сделать: Как поменять Windows 10 32-бит на 64-бит.

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

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

Если это не сработает, выполните еще одну попытку, изменив PoolUsageMaximum на 40 и не забыв перезагрузить компьютер.

Надеюсь, один и вариантов сработает в вашем случае и позволит избавиться от рассмотренной ошибки. Если же нет — опишите подробно ситуацию в комментариях, возможно мне удастся помочь.

А вдруг и это будет интересно:

21.02.2018 в 14:45

Изменение параметров выгружаемого пула памяти в редакторе реестра. Прошёл все шаги всё по старому помогает только выключение, а при перезагрузке гаснет монитор клавиатура тоже все диоды гаснут, и мигает индикатор монитора. Нажимаю кнопку стоп и тут же запускаю, windows с сигналом стикира запускается. Может мне уступили процессор с повреждением, но это вряд ли тогда бы он не работал.

14.06.2018 в 20:25

17.07.2018 в 10:11

25.08.2018 в 06:04

25.08.2018 в 14:20

10.01.2019 в 23:10

Такая же проблема но только на windows xp на самом начале запуска

21.05.2019 в 08:55

Не могу запустить игру (unturned) пишет недостаточно системных ресурсов и ничего не помогает.

21.05.2019 в 10:26

А файл подкачки не отключали случайно?

14.10.2019 в 10:53

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

14.10.2019 в 14:07

29.04.2020 в 12:47

29.04.2020 в 15:13

Здравствуйте. В инструкции указано, что вы можете его создать.

09.08.2021 в 16:27

10.08.2021 в 11:04

Здравствуйте.
А при ошибке у нас что вообще показывает по памяти в диспетчере задач? Действительно ли заполнена? Видно ли в процессах чем именно?

11.10.2021 в 18:09

СПАСИБО большое, для меня статья оказалось очень полезной

04.11.2021 в 22:21

Здравствуйте, Дмитрий! У меня проблема с запуском программ corel, (Corel Painter Essentials 7 и Corel Painter 2022) в случае с первой она запускается и мне доступна панель настроек холста но сам холст не прогружается и программа перестает работать, в случаи со второй отображается проблема (недостаточно системных ресурсов для завершения операции в Windows) и так же как и в первом случаи отображается панель, но вскоре программа перестает работать. Пробовала ваши советы, но к сожалению ничего не помогло. До этого я уже использовала Corel Painter Essentials 7 на этом ноутбуке и все прекрасно работало. Заранее спасибо за ответ.

06.11.2021 в 10:03

06.11.2021 в 19:29

Здравствуйте,
Нет, файл подкачки не отключала и по вашим советам установила на уровне рекомендуемого объема. Место на диске С 13,9 Гб.

07.11.2021 в 19:17

Тогда, боюсь, не знаю, что еще предположить. Я сам корелом не пользуюсь, но может оказаться, что ему действительно недостаточно оперативной памяти (8 Gb RAM требуется для Painter 2022).
А еще может быть, что антивирус мешает (берусь предположить, что программы у вас не самые лицензионные, хотя могу и ошибаться)

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