2010-12-05 2 views
0

У меня есть приложение WinForms, в котором я хочу иметь возможность редактирования HTML. Поэтому я перевел Lutz Roeder's HTML Writer из C# в VB.NET и преобразовал его из формы Windows в пользовательский элемент управления пользователя, который теперь размещен в дочерней форме MDI.Как найти источник неуправляемого исключения?

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

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

Я также включил неуправляемого кода отладки (я использую 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, но я изо всех сил пытаюсь понять, где искать.

Edit:

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

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

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 

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

+0

Не можете ли вы присоединить отладчик с помощью VS и найти исключение, которое бросается? Неуправляемые исключения обычно содержат больше информации в массиве «Detail» внутри них. – Darbio 2010-12-05 12:10:18

+0

Чтобы подключить (из памяти), это Debug> attach to process, а затем загрузить любые символы, которые вам нужны (файл .pdb). – Darbio 2010-12-05 12:10:56

ответ

1

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

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

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

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

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

0

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

Смежные вопросы