Произошла исключительная ситуация microsoft cursor engine недостаточно памяти

Обновлено: 07.01.2025

Обычно, чтобы избавиться от этого, мне нужно перезапустить Visual Studio.

Сборка, которую мне нужно использовать в моем проекте, достаточно БОЛЬШАЯ (> 70 Мб) и, вероятно, это причина той ошибки, я никогда не видел ничего подобного в своих предыдущих проектах. Хорошо, если это причина, мой вопрос: почему это происходит, и что мне нужно сделать, чтобы это остановить.

У меня достаточно свободной памяти на моих дисках и 2 ГБ ОЗУ (в случае исключения используется только

Я искал в Google ответы на подобные вопросы.

Предложения обычно связаны с:

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

Я не думаю, что это может объяснить мой случай

Для обработчиков пользователей и других ресурсов графического интерфейса - я не думаю, что это может быть проблемой. Большая 70-мегабайтная сборка на самом деле представляет собой код без графического интерфейса пользователя, который работает с сокетами и реализует парсеры проприетарных протоколов. В моем текущем проекте у меня есть только 3 формы графического интерфейса, с общим количеством элементов управления графическим интерфейсом CLR , когда он загружает метаданные сборки).

Ошибка вводит в заблуждение. Он действительно должен сказать: «Не удалось найти достаточно большое непрерывное пространство в виртуальной памяти для выполнения операции». Со временем выделение и освобождение пространства виртуальной памяти приводит к его фрагментации. Это может привести к ситуациям, когда большой объем памяти не может быть заполнен, несмотря на наличие достаточного общего пространства.

Я думаю, это то, к чему относится ваша «сегментация». Не зная всех подробностей обо всем остальном, что необходимо загрузить, и о другой деятельности, которая занимает 2-3 часа, трудно сказать, действительно ли это является причиной. Однако я бы не стал относить это к категории маловероятных, на самом деле это наиболее вероятная причина.

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

Слишком много проектов в решении.
Сторонние надстройки

Если у вас в решении более 10 проектов. Попробуйте разбить раствор и посмотрите, поможет ли это.

Если у вас есть какие-либо сторонние надстройки, попробуйте отключить их по одному и посмотреть, исчезнет ли проблема.

Я получаю эту ошибку на одной из своих машин, и, что удивительно, эта проблема не наблюдается на других машинах разработчиков. Может что-то не так с установкой VS. Но я нашел более простое решение. Если я удалю файл .suo решения и снова открою решение, оно начнет работать без сбоев. Надеюсь, это будет полезно для кого-то, кто попал в беду.

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

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

Что касается вашей проблемы, Богдан, вы пытались воспроизвести проблему без загруженного компонента C ++? Если не можешь, то, может быть, дело в этом. Как вы загружаете компонент? пробовали ли вы другие методы, например, позднее связывание и т. д.? какая разница?

Если использование памяти и размер виртуальной машины мал для devenv. Явно уничтожьте «ВСЕ» экземпляры запущенного devenv.exe.

У меня было запущено 3 devenv.exe, так как у меня было открыто два экземпляра Visual studion.

В моем случае это было решением.

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

В разделе «Инструменты / Папка / Просмотр» в разделе «Файлы и папки» есть параметр «Запускать окна папок в отдельном процессе».

Снятие отметки решило проблему.

Просто прохожу как еще одно возможное решение

Я тоже столкнулся с той же проблемой. Убедитесь, что операционная система Windows 64-битная. Я перешел на Windows 64bit из Windows 32bit. Проблема решена.

У меня была такая же проблема, и в моем случае имя исключения вводило в заблуждение. Фактическая проблема заключалась в том, что DLL вообще не могла быть загружена из-за неверного пути. Исключение, которое мне сказали "

Ниже приведен рабочий фрагмент кода:

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

Вряд ли профайлер поможет.

А профайлер с включенной трассировкой ошибок что показывает?

Вряд ли профайлер поможет.

А параметры как передаете?

И еще, самому лень проверять, но
Если в QA или в SQL SMS выполнить:

Вернет ли такой вызов названия столбцов?
Назваение столбцов выводить.
Параметры после каждого изменения поля фильтров пересобираю. Вот код:

Если все параметры в ХП равны 0 или NULL, Sql строка у вас собирается неправильно.
Не будет пробела перед ORDER BY - и выскочит TSQL ошибка.

Посмотрите профайлером, что происходит в момент:

Есть вероятность (самому лень смотреть) что Акс сделает такой вызов:

set fmtonly on
exec spPRojectView 0,0,0,0,0
set fmtonly off

Посмотрите профайлером, что происходит в момент:

Есть вероятность (самому лень смотреть) что Акс сделает такой вызов:

set fmtonly on
exec spPRojectView 0,0,0,0,0
set fmtonly off

Посмотрите профайлером, что происходит в момент:

Есть вероятность (самому лень смотреть) что Акс сделает такой вызов:

set fmtonly on
exec spPRojectView 0,0,0,0,0
set fmtonly off

для того чтобы определить форматы полей рекордсета. И вернет эту ошибку.
Профайлер пишет
Подобный строк как вы писали нет.

Посмотрите профайлером, что происходит в момент:

Есть вероятность (самому лень смотреть) что Акс сделает такой вызов:

set fmtonly on
exec spPRojectView 0,0,0,0,0
set fmtonly off

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

Мыслей больше нет. Но можно попробовать сделать недокументированную вещь:
1. перенести контролы

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

2. В рекордсоурс подформы fsubMainPRoject поставить строку:

3. Отключить сборку InputParameters - теперь параметры передаваться автоматически при изменении любым способом их значений (это как раз и недокументировано), а подформа будет обновляться.

4. Обновление подформы производить выполняя код:
- параметр изменился, подформа обновилась

Мыслей больше нет. Но можно попробовать сделать недокументированную вещь:
1. перенести контролы

2. В рекордсоурс подформы fsubMainPRoject поставить строку:

4. Обновление подформы производить выполняя код:
- параметр изменился, подформа обновилась

Причина

Решение №1

Определите разрядность платформы для конфигурации 1С, которая используется на компьютере. Для этого запустите диспечер задач Windows, перейдите на вкладку «Процессы» и проверьте название процесса 1С.
- 1cv8ct.exe *32 — это 32-разрядная платформа (x86);
- 1cv8ct.exe *64 — это 64-разрядная платформа (x64).

Если вы используете клиент-серверную версию 1С, проверку нужно выполнять на компьютере, где установлена серверная часть.

1С x86, а MS Office x86 или не установлен — скачайте драйвер x86;
1С x64, а MS Office x64/x86 или не установлен — скачайте драйвер x64.

1С x86, а MS Office x64;
используется клиент-серверная версия 1С: клиент на компьютере с ОС Windows, а на сервере другая ОС.

В этих случаях воспользуйтесь другим решением.

Решение №2

Определите каталог хранения настроек 1С.
По-умолчанию это «С:\Sbis1C». В зависимости от режима работы, настройки могут храниться на сервере вместе с базой 1С или на локальном компьютере.
В зависимости от конфигурации 1С, скачайте файл *.xml:
- для 1С: «Управление торговлей» версия 10 , «Управление производственным предприятием» — файл настроек.
- для 1С: «Управление торговлей» версия 11, «ERP», «Бухгалтерия государственного учреждения», «Бухгалтерия сельскохозяйственного предприятия», «Бухгалтерия 2.0», «Бухгалтерия 3.0», «Комплексная автоматизация 2.0», «Управление нашей фирмой 1.0» — файл настроек.
Переименуйте скачанный файл в соответствии с другими файлами настроек, но не указывайте расширение «sbis».

Например: имя файла в настройках имеет вид «ВО82КА1-1-36_Конфигурация.sbis3.xml». Скачанный файл назовите «ВО82КА1-1-36_Конфигурация.xml»

Симптомы

OutOfMemoryException: "Недостаточно памяти в указанном диапазоне адресного пространства для продолжения выполнения программы".

Причина

Это исключение из памяти распространяется с помощью CLR, когда подсистема диспетчера кода не может выделить память в определенном диапазоне адресного пространства для скачок. (Эти загдры перехода соответствуют методу, который вызывает в библиотеках динамических ссылок (DLLs), расположенных на 2 ГБ или более друг от друга в пространстве адресов.) В радиусе 2 ГБ от вызываемого метода должно быть пространство для хранения загной прыжка для 64-битного вызова метода. Приложение не может восстановиться после этой конкретной ошибки. Таким образом, состояние приложения после того, как оно отвечает этой ошибке, неизвестно, и его следует считать поврежденным. Единственный способ восстановления — перезапустить приложение.

Обходной путь

Чтобы решить эту проблему, используйте один из следующих методов настройки:

Реализация параметра для всей машины, добавив следующий ключ реестра:

Реализуйте параметр уровня приложений, добавив следующий раздел в файл config приложения:

NGenReserveForJumpStubs заставляет CLR зарезервировать процент адресного пространства для скачок загружных загрезов рядом с каждым загруженным изображением NGen. Мы рекомендуем использовать значение 5 или больше, если вы испытываете это OutOfMemoryException .

Сведения для разработчиков

Смягчения JIT и NGen работают несколько по-другому. Оба они зарезервировать дополнительное пространство адресов вперед, но точка, где это бронирование сделано отличается между ними.

NGenReserveForJumpStubs это процент от размера виртуального изображения NGen(percentReserveForJumpStubs).

Типичная загитовка прыжка — 12 bytes. Дополнительные сведения см. в JUMP_ALLOCATE_SIZE.

Память выделяется и резервируется рядом с адресом, где было загружено изображение NGen (точный алгоритм — EEJitManager::EnsureJumpStubReserve. Память передается при необходимости выделения загона для прыжка, а также в отсутствие другого подходящего адресного пространства.

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

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

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

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

Установка более высокого значения может привести к снижению производительности и риску возникновения NGenReserveForJumpStubs других тонких проблем.

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