Необработанное исключение типа system stackoverflowexception произошло в mscorlib dll

Обновлено: 02.07.2024

Я получаю ошибку необработанное исключение типа " System.StackOverflowException " произошло в Forte Sender.exe в моем коде. У меня есть понимание, что это означает, что в моем коде есть бесконечный цикл, но я, кажется, не могу найти этот цикл. Вот мой код:

Поэтому я заметил, что если я выну MainBox MainBoxWindow = new MainBox(); , то программа будет работать правильно. Но мне нужен этот экземпляр там, чтобы вызвать функцию в форме 1. Как я могу обойти эту проблему? Либо другой способ вызова функции, либо решение бесконечного цикла.

4 ответа

Ну, ваш MainBox создает ApplicationProperties , который , в свою очередь , создает MainBox , который создает ApplicationProperties , и так до бесконечности. Очевидно, вам нужно разорвать этот цикл.

Поскольку ваш код стоит прямо сейчас, вы, вероятно, захотите удалить new MainBox() для формы свойств и ввести его позже, например:

Вы просто открываете одну форму, и она открывает другую из своего конструктора, и она снова открывает первую в конструкторе t и так далее.

Инициализаторы полей выполняются непосредственно перед конструктором при создании экземпляра.

Ваш класс ApplicationProperties создает объект MainBox , а ваш объект MainBox создает объект ApplicationProperties . Это и есть петля. Каждый вызов new - это еще один вызов конструктора в этом цикле. Конструкторы называют друг друга терминами в так называемой взаимной рекурсии, которая приводит к вашему stack overflow.

Вы создаете MainBox внутри ApplicationProperties и ApplicationProperties внутри MainBox это будет продолжать создавать экземпляры в результате StackOverFlowException

Чтобы избежать этого, вы могли бы создать экземпляры в переопределенном методе OnLoad , но создание экземпляров, взаимно связанных, не имеет смысла.

Примеры

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

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

StackOverflowException использует COR_E_STACKOVERFLOW HRESULT, имеющий значение 0x800703E9. LocallocВыдается инструкция промежуточного языка (IL) StackOverflowException . Список начальных значений свойств для StackOverflowException объекта см. в разделе StackOverflowException конструкторы.

Если в приложении размещается среда CLR, можно указать, что среда CLR должна выгрузить домен приложения, в котором произошло исключение переполнения стека, и разрешить выполнение соответствующего процесса. Дополнительные сведения см. в разделе интерфейс ICLRPolicyManager.

Конструкторы

Свойства

Возвращает коллекцию пар «ключ-значение», предоставляющую дополнительные сведения об исключении.

Получает или задает ссылку на файл справки, связанный с этим исключением.

Возвращает или задает HRESULT — кодированное числовое значение, присвоенное определенному исключению.

Возвращает экземпляр класса Exception, который вызвал текущее исключение.

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

Получает строковое представление непосредственных кадров в стеке вызова.

Возвращает метод, создавший текущее исключение.

Методы

Определяет, равен ли указанный объект текущему объекту.

При переопределении в производном классе возвращает исключение Exception, которое является первопричиной одного или нескольких последующих исключений.

Служит хэш-функцией по умолчанию.

При переопределении в производном классе задает объект SerializationInfo со сведениями об исключении.

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

Создает неполную копию текущего объекта Object.

Создает и возвращает строковое представление текущего исключения.

События

Возникает, когда исключение сериализовано для создания объекта состояния исключения, содержащего сериализованные данные об исключении.

все что я слышу-это: необработанное исключение типа System.StackOverflowException ' произошло в тег-ты-это.dll файлы

варианты:

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

PS:

это гипотетическая ситуация (хотя и не слишком редко) и поэтому код недоступен.

WinDbg может выполнить работу, включая даже получение разумной трассировки стека (clr). Вам нужно будет получить WinDbg Если вы еще не установили его с помощью Visual Studio или Windows SDK. Примечание:" WinDbg Preview " с новым GUI отлично работал для меня.

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

Примечание: сразу после запуска процесса среда CLR не загружается, и .loadby SOS.dll clr не удастся. Вы должны позволить процессу работать некоторое время и ждать загрузки среды CLR)

Как только вы это сделаете, вам придется выполнить следующие шаги (введите в окне / строке команды):

.loadby SOS.dll clr (не .loadby SOS clr-это может привести к загрузке расширения дважды)
.!stoponexception-создать Система.Исключения StackOverflowException
g (продолжает отладки)

вызовите StackOverflowException / подождите, пока это произойдет

!clrstack (напечатает stacktrace)

это почти всегда связано с рекурсией. Либо метод, вызывающий сам себя, либо метод, вызывающий метод, который вызывает его обратно и так далее.

обновлено: Я не понял, но, по-видимому, вы не можете получить трассировку стека для StackOverflowException (Я думаю, что-то делать с тем, чтобы не поймать один, либо). Однако есть способы получить дамп как уже упоминалось здесь.
ReSharper покажет методы, которые вызывают сами (он помещает небольшой зеленый круг в боковую панель для рекурсивных вызовов), хотя он не поймает рекурсию, где задействованы два или более методов.
используйте такой инструмент, как профилировщик муравьев, чтобы узнать, какие методы вызываются чаще всего.
следите за событиями, которые могут вызвать код, который означает, что одно и то же событие снова срабатывает, вызывая цикл.

иногда вы получите опечатки, как это тоже:

что является одной из причин, почему Я лично сейчас предпочитаю использовать автоматические свойства.

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

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

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

Как только вы заметите это, поставьте точку останова в текущем местоположении, где бы это ни было. Продолжить выполнение (F5 в Visual Studio) - Если вы на правильном пути, то отладчик остановится очень быстро на то же место, и стек вызовов будет еще глубже.

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

Если у вас есть код и вы можете запустить свою программу из Visual Studio, она должна сломаться в отладчике (если включены исключения первого шанса) при встрече с системой.исключение StackOverflowException. Оттуда вы можете изучить стек вызовов и посмотреть, какие вызовы выдувают стек.

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

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

затем я прошел через мои функции и добавил, Как функции печати, такие как: Так же, как функция начинается:

как раз перед функцией возвращает:

где GetCurrentMethod определяется как:

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

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

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

довольно просто и быстро найдете, где это происходит.

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

Поскольку это исключение StackOverflow, мне показалось, что это лучшее место, чтобы спросить об этом!

4 ответа

В документации для события TreeView.AfterCheck говорится:

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

РЕДАКТИРОВАТЬ:

Здесь нет необходимости проверять e.Action, да и не следует по двум причинам:

Поскольку вы перечисляете дочерние элементы проверенного узла, у вас не будет проблем с бесконечной рекурсией, которая была в исходном коде.
Если вы выйдете, когда e.Action = unknown, то, если у вас есть 3 уровня в древовидной структуре, он выберет только непосредственных потомков выбранного вами узла, а не всех потомков.

Вызывает само событие TreeView1_AfterCheck . Так что это бесконечный цикл.

Вам нужно переписать код более тщательно, чтобы вы не повторно назначали Checked = True , если Checked уже истинно, и, возможно, использовать частное поле, чтобы проверить, запущено ли уже текущее событие. при входе.

Что происходит, так это то, что в событии AfterCheck вы «проверяете» узел дерева, который запускает событие AfterCheck, в котором вы «проверяете» узел, которое запускает событие AfterCheck, в котором вы «проверяете» узел, который запускается. событие AfterCheck, в котором вы «проверяете» узел, которое запускает событие AfterCheck, в котором вы «проверяете» узел, которое запускает событие AfterCheck, в котором вы «проверяете» узел, который запускает событие AfterCheck, в в котором вы «проверяете» узел, который запускает событие AfterCheck, в котором вы «проверяете» узел, которое запускает событие AfterCheck, в котором вы «проверяете» узел, которое запускает событие AfterCheck, в котором вы «проверяете» узел, который запускает событие AfterCheck, в котором вы «проверяете» узел, которое запускает событие AfterCheck, в котором вы «проверяете» узел, которое запускает событие AfterCheck, в котором вы «проверяете» узел, который запускается событие AfterCheck, в котором вы «проверяете» узел, что вызывает переполнение стека.

Необработанное исключение типа system.stackoverflowexception произошло в mscorlib.dll

У меня есть класс с именем Carroms. Когда я создаю его объект, ошибки нет. Но когда я создаю массив Carroms тогда возникает это исключение:

Необработанное исключение типа System.Reflection.TargetInvocationException произошло в PresentationFramework.dll

Дополнительная информация: исключение было вызвано целью вызова.

Мой код для Carroms класс:

И мой код для создания объекта:

Вы создаете массив, но all items added in array are still null .

Initialize them first и тогда только вы можете получить к нему доступ. Проблема здесь -

Или вы можете использовать array initializer чтобы инициализировать его -

1 Рад помочь Аффуу. Кстати, постарайтесь строго соблюдать соглашения об именах, предоставленные Microsoft для именования вашего класса. Это можно найти здесь.
1 о. Замечательно. В Java этого бы не произошло. Спасибо за ваше решение. Java неявно создаст объект для каждого элемента массива. Довольно интересно!
@ChristianSchack Это неправда. Если вы создаете массив ссылочного типа в Java, все элементы null если вы их не инициализируете.
@Clemens Thx за ваш совет. Да, я думаю, ты прав. Таким образом, эта проблема приводит также в Java к InvoactionTargetException, что действительно неверно, потому что основной причиной является NullPointerException, потому что теперь создается экземпляр, на котором может обрабатываться TargetInvocation.

Хотите что-то добавить, не пугайтесь TargetInvocationException, поскольку оно не предоставляет слишком много информации. Вы должны увидеть внутреннее исключение, чтобы определить основную причину. InnerException может иметь тип AggregateException, в этом случае вам нужно спуститься ниже, чтобы получить все подробности исключения.

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

Необработанное исключение типа system stackoverflowexception произошло в mscorlib dll

4 ответа

Похожие вопросы:

Примеры

Комментарии

Конструкторы

Свойства

Методы

События

4 ответа

Необработанное исключение типа system.stackoverflowexception произошло в mscorlib.dll