Как найти источник неуправляемого исключения? - PullRequest
0 голосов
/ 05 декабря 2010

У меня есть приложение WinForms, в котором я хочу предоставить возможность редактирования HTML. Поэтому я перевел HTML Writer Лутца Редера из C # в VB.NET и преобразовал его из оконной формы в пользовательский элемент управления, который теперь размещается в дочерней MDI-форме.

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

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

Я также включил отладку неуправляемого кода (я использую VS2010, компилирую для x86 и Framework 3.5), и все, что я получаю, это:

Windows has triggered a breakpoint in HtmlEditorMdi.exe.
This may be due to a corruption of the heap, which indicates a bug in HtmlEditorMdi.exe or any of the DLLs it has loaded.
This may also be due to the user pressing F12 while HtmlEditorMdi.exe has focus.
The output window may have more diagnostic information.

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

Что я действительно ценю, так это некоторые идеи о том, как искать эту проблему. Может быть, конечно, что я сделал ошибку в преобразовании C # в VB, но я изо всех сил пытаюсь узнать, где искать.

Редактировать :

Я запустил приложение с подключенным отладчиком, и он не дал мне ничего полезного.

Все, что я получаю, это сообщение Windows «Приложение перестало работать», с этим в деталях проблемы:

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: HtmlEditorMdi.exe
  Application Version:  1.0.0.0
  Application Timestamp:    4cfb74c7
  Fault Module Name:    mscorwks.dll
  Fault Module Version: 2.0.50727.4952
  Fault Module Timestamp:   4bebd49a
  Exception Code:   c0000005
  Exception Offset: 000022b5
  OS Version:   6.1.7600.2.0.0.256.1
  Locale ID:    2057
  Additional Information 1: 0a9e
  Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
  Additional Information 3: 0a9e
  Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Я вижу, что это нарушение прав доступа, но даже если я уйду Отладка> Исключения> Исключения Win32 и отметка c0000005 , я ничего не получу, когда он сломается - просто «источник недоступен».

Ответы [ 2 ]

1 голос
/ 05 декабря 2010

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

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

Этот вид повреждения кучи неизменно вызывается неуправляемым кодом. Исключение AccessViolation - это известное зло для программистов на C / C ++ и очень веская причина, по которой управляемый код стал популярным. Хотя исходный код Lutz полностью управляется, он содержит lot объявлений P / Invoke и COM-интерфейса. Нет хорошего способа их отладки, у вас нет исходного кода.

Понимание того, что одно из этих объявлений немного неверно, когда вы конвертируете их в VB.NET, безусловно, может быть одним из таких способов. Также вполне может быть, что ошибка всегда была там, но подняла свою уродливую голову только сейчас. Повезло тебе. Кстати, я не думаю, что код 64-битный чистый, заставить его работать в 32-режиме для возможного быстрого исправления. Для вашего основного проекта EXE: Project + Properties, вкладка Compile, прокрутите вниз, Advanced Compile Options, Target CPU = x86. Это относится только к 64-разрядной версии Windows.

Кроме этого, я бы рекомендовал вам использовать проект C # как есть. Смешивание языков в решении - очень хорошо поддерживаемый сценарий в .NET.

0 голосов
/ 05 декабря 2010

Отладчик windbg - это «большая пушка» для такого рода проблем.Он может часто давать вам подсказки, рассказывая вам об обработанных исключениях и т. Д. Единственная проблема с ним заключается в том, что его нелегко использовать и он имеет очень высокую кривую обучения.

...