Итак — есть С++ код, которому надо обратиться к функционалу, работающему только в дотнет библиотеке, чтоб её...
Для этого по совету с MSDN накатали на С++ прокси-dll, в которой идет перевод обращений от С++ в COM объект,
который создан на C# на основе интерфейсных функций из дотнетовской библиотеки. Вроде принципиально все заработало.
НО вдруг стало порой выдавать окно — мол приложение совершило бяку и будет закрыто...
Приклеили запись стектрейсов и минидампов на нашу C++ прогу. И удивились — ибо стектрейс выдавал lite трейс с либами,
которые тока в дотнете существуют. Хммм.. Значит не вы виноваты, но! проблема, что стектрейс не полный (нет
интерфейса функций — мы видим тока библиотеки CLR времени исполнения дотнета), дамп тоже ничего не показывает
нормального — видимо не может он записать/показать инфу по managed коду, когда мы его вызываем из С++'ного.

Вопрос — КАК правильно написать ловлю исключительных ситуаций под дотнет код — не имея доступа к этому коду,
который содержится в юзаемой нами дотнет библиотеке. У нас тока доступ к managed коду создания COM объекта,
и к С++ коду прокси либы. Мы хотим чтоб при возникновении каких либо фиговых ситуаций в нутрях дотнета — мы
получали полноценный стектрейс, характерный именно для managed кода (со всеми верными функциями) и чтоб писался
такой дамп, который при открытии мог показать именно внутренности дотнет среды исполнения — со всеми локальными
переменными с переменными в куче и т.д. Для С++ у нас это вышло — но походу для того, чтоб это сработало для
дотнет либы надо чтото особенное проделать....

Здравствуйте,

Дампы раскрываются только под дот нет 4. Просто переходите на него если можете.

Почему не пользуетесь интерроп(managed c++), по мне так удобней и больше возможностей.

А>Вопрос — КАК правильно написать ловлю исключительных ситуаций под дотнет код — не имея доступа к этому коду,

напишите свою .NET обертку над либой, в которой сделайте логирование всех unhanled exceptons
http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx

Здравствуйте, igor-booch, Вы писали:

А>>Вопрос — КАК правильно написать ловлю исключительных ситуаций под дотнет код — не имея доступа к этому коду,

IB>напишите свою .NET обертку над либой, в которой сделайте логирование всех unhanled exceptons
IB>http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx

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

Дамп нужно сохранять не в catch — там уже слишком поздно, стек раскручен, локальные переменные потеряны. А нужно внутри exception filter.
В интернете полно примеров сохранения managed dump, при этом я не видел ни одного 100% правильного. Но это легко допиливается вручную, если разобраться как все работает.

Здравствуйте, abibok, Вы писали:

A>Дамп нужно сохранять не в catch — там уже слишком поздно, стек раскручен, локальные переменные потеряны. А нужно внутри exception filter.
A>В интернете полно примеров сохранения managed dump, при этом я не видел ни одного 100% правильного. Но это легко допиливается вручную, если разобраться как все работает.

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

А>логирование? эммм. хотелось бы полные дампы и стектрейс — как я указал в стартовом топике.
пожалуйста логируйте стектрейс, он есть в классе Exception, не забудьте про InnerException
log4net вам в помощь
По дампам не знаю, посмотрите http://blogs.msdn.com/b/tess/archive/2009/06/16/first-look-at-debugging-net-4-0-dumps-in-visual-studio-2010.aspx

IB>пожалуйста логируйте стектрейс, он есть в классе Exception, не забудьте про InnerException

1) Для этого придется вставлять код логирования во все catch.
2) Стектрейс может быть искажен, если исключение ловилось и перебрасывалось внутри try-catch.
3) Исключение в parallel task может сидеть незамеченным, если мы не получаем результат таска, а потом убьет процесс при выполнении финализатора.
4) Не поможет, если у нас несколько исключений одновременно, например что-то крэшится в finally, dispose или конструкторе объекта.
5) Логировать имеет смысл только unhandled exceptions, а не все. Как это определить в конкретном catch? Можно через рефлексию пройти по стеку вверх и найти все вышестоящие catch, но это дорого и ненадежно.

Если лень/нет времени заниматься полноценным решением, стоит хотя бы добавить свой обработчик на AppDomain.UnhandledException event (http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx)

Сохранять дамп нужно из своего процесса, чтобы не потерять контекст исключения. При этом лучше из отдельного потока, который нужно создать в начале работы приложения, чтобы вносить как можно меньше шума. Не забудьте про Process.EnterDebugMode и то, что Id потока с исключением должен быть native, а не managed.

Здравствуйте, abibok, Вы писали:

IB>>пожалуйста логируйте стектрейс, он есть в классе Exception, не забудьте про InnerException

A>1) Для этого придется вставлять код логирования во все catch.
A>2) Стектрейс может быть искажен, если исключение ловилось и перебрасывалось внутри try-catch.
A>3) Исключение в parallel task может сидеть незамеченным, если мы не получаем результат таска, а потом убьет процесс при выполнении финализатора.
A>4) Не поможет, если у нас несколько исключений одновременно, например что-то крэшится в finally, dispose или конструкторе объекта.
A>5) Логировать имеет смысл только unhandled exceptions, а не все. Как это определить в конкретном catch? Можно через рефлексию пройти по стеку вверх и найти все вышестоящие catch, но это дорого и ненадежно.

A>Если лень/нет времени заниматься полноценным решением, стоит хотя бы добавить свой обработчик на AppDomain.UnhandledException event (http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx)

A>Сохранять дамп нужно из своего процесса, чтобы не потерять контекст исключения. При этом лучше из отдельного потока, который нужно создать в начале работы приложения, чтобы вносить как можно меньше шума. Не забудьте про Process.EnterDebugMode и то, что Id потока с исключением должен быть native, а не managed.

Товарищи — еще раз — в дотнет мы полезли — потому что определенное устройство работает тока через дотнет либу.
Мы вообще то программисты тока С++. Поэтому все умные слова, связанные с дотнетом, чтоб билл им икался месяц...
просьба переводить или на чисто русский — или дать ссылки на эту самую предметную область, где более менее корректно все сделано/расписано.
Ибо фраза "Не забудьте про Process.EnterDebugMode" — не вносит ни какого прояснения. Не забыть о чем? О том что такая функция есть? Ее обязательно надо вызывать? Или не вызывать? Или перехватчик-обработчик на нее повесить? Или все действия тока после нее/из нее можно делать...
Мы прекрасно понимаем как дамп под С++ писать — но под дотнет, чтоб его....
Потому — если хоть какой то полноценный вариант кода, реализующего хоть насколько-то верный подход, для дампинга
вы знаете — то просто покажите, ткните носом. У нас реально нет времени изучать все примочки дотнета с нуля. И все его подводные камни...

Здравствуйте, abibok, Вы писали:

IB>>пожалуйста логируйте стектрейс, он есть в классе Exception, не забудьте про InnerException

A>1) Для этого придется вставлять код логирования во все catch.
A>5) Логировать имеет смысл только unhandled exceptions, а не все. Как это определить в конкретном catch? Можно через рефлексию пройти по стеку вверх и найти все вышестоящие catch, но это дорого и ненадежно.
A>Если лень/нет времени заниматься полноценным решением, стоит хотя бы добавить свой обработчик на AppDomain.UnhandledException event (http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx)
Скажите что значит полноценное решение?


A>2) Стектрейс может быть искажен, если исключение ловилось и перебрасывалось внутри try-catch.
A>3) Исключение в parallel task может сидеть незамеченным, если мы не получаем результат таска, а потом убьет процесс при выполнении финализатора.
A>4) Не поможет, если у нас несколько исключений одновременно, например что-то крэшится в finally, dispose или конструкторе объекта.
Если в библиотеке исходный код которой недоступен неправильно обрабатываются исключения, то тут уже ничего не поделаешь. Может только дампы помогут.

Поясню свое решение во избежании недоразумений:

Есть библиотека, исходный код которой недоступен

class Lib
{

    void A(...)
   {
   ...
   }

   void B(...)
   {
   ...
   }
}

обращаемся из C++ не напрямую к этой библиотеке, а к обертке

class LibWrapper
{
   public LibWrapper()
   {
       AppDomain.CurrentDomain.UnhandledException += (s, eventArgs) => 
       {
           //логирование
       }

   }

   void A(...)
   {
   ...
   }

   void B(...)
   {
   ...
   }
}

Что Вы предлагаете?

Может проще нанять человека, который умеет? Дешевле выйдет. А здесь все равно никто не даст рабочих исходников. 90% в этой теме не рубят, остальные связаны NDA.

Здравствуйте, abibok, Вы писали:

A>Может проще нанять человека, который умеет? Дешевле выйдет. А здесь все равно никто не даст рабочих исходников. 90% в этой теме не рубят, остальные связаны NDA.

чтоб нанять такого — надо быть уверенным — что такой чувак есть. И если в своей С++ сфере мы понимаем КАК искать и ГДЕ искать,
если вдруг понадобится такое дело — то в дотнете — это "первый раз в первый класс". И результаты могут быть непредсказуемыми.
Этот нанятый — может точно также из инета по быстрому скачать пару примеров — их коды переложить на наш код и свалить.
А мы потом будем расхлебывать....
А этот NDA.... Вы реально верите в его силу и необходимость и придерживаетесь его? Особенно в случае микрокуска кода?
несвязанного с какой-то патентной областью или ноу-хау конторы?

Здравствуйте, Аноним, Вы писали:

А>А этот NDA.... Вы реально верите в его силу и необходимость и придерживаетесь его? Особенно в случае микрокуска кода?
А>несвязанного с какой-то патентной областью или ноу-хау конторы?

Вы выбрали КОМ обёртку. Это не двух минутный патч. Вам нужно полностью переписать обёртку и добавить всё что уже упоминалось. Это работа, и не на один день. Ищите человека, вопросы и ответы вас ни куда не продвинут.

Здравствуйте, Caracrist, Вы писали:

C>Здравствуйте, Аноним, Вы писали:

А>>А этот NDA.... Вы реально верите в его силу и необходимость и придерживаетесь его? Особенно в случае микрокуска кода?
А>>несвязанного с какой-то патентной областью или ноу-хау конторы?

C>Вы выбрали КОМ обёртку. Это не двух минутный патч. Вам нужно полностью переписать обёртку и добавить всё что уже упоминалось. Это работа, и не на один день. Ищите человека, вопросы и ответы вас ни куда не продвинут.

не могли бы вы уточнить — а что ВСЁ именно тут упоминалось? Я тока реально видел предложение о AppDomain.UnhandledException event.
а вопросы и ответы — ВСЕГДА, запомните, ВСЕГДА куда то да приводят и дают нужную пищу для размышлений и действий.

Здравствуйте, Аноним, Вы писали:

А>но! проблема, что стектрейс не полный (нет
А>интерфейса функций — мы видим тока библиотеки CLR времени исполнения дотнета), дамп тоже ничего не показывает
А>нормального — видимо не может он записать/показать инфу по managed коду, когда мы его вызываем из С++'ного.

Можно подробнее каким образом вы пытались смотреть managed стеки? Расширением sos для WinDbg пользовались?

Здравствуйте, Аноним, Вы писали:

Можно запускать managed код под самодельным отладчиком: http://msdn.microsoft.com/en-us/library/ms404484.aspx

А>>но! проблема, что стектрейс не полный (нет
А>>интерфейса функций — мы видим тока библиотеки CLR времени исполнения дотнета), дамп тоже ничего не показывает
А>>нормального — видимо не может он записать/показать инфу по managed коду, когда мы его вызываем из С++'ного.

BB>Можно подробнее каким образом вы пытались смотреть managed стеки? Расширением sos для WinDbg пользовались?

Если у вас есть дампы падения, то вполне возможно вся информация в них уже есть и дополнительно ничего прикручивать не нужно. Просто для анализа managed стека используются не те команды отладчика, что для анализа нативного (C++) кода. Начните с команды !analyze -v. Если она не показывает стек и исключение, можно попробовать так:

.loadby sos mscorwks // для .NET 3.5 и ниже

или

.loadby sos clr // для .NET 4.0 и выше

далее, например

~* e !dumpstack

Эта команда должна показать стеки всех потоков в дампе, включая managed.

Во-первых, лучше psscor, чем sos.
А во-вторых, windbg не поможет, если дамп сохранен неправильно. Т.е. ничего более полезного, чем стек исключения, аналогичный тому, что показывает Exception.ToString(), там не будет. Причем для интеропа clr-com такой стек будет совершенно не информативным в плане расследования проблемы.

Нужен человек, который как минимум понимает чем отличается 6BA от 6BE.

Здравствуйте, abibok, Вы писали:

A>Во-первых, лучше psscor, чем sos.
Лучшее враг хорошего.

A>А во-вторых, windbg не поможет, если дамп сохранен неправильно. Т.е. ничего более полезного, чем стек исключения, аналогичный тому, что показывает Exception.ToString(), там не будет.
Да, если что-то делать неправильно, то это не поможет. Предлагаю сохранять дамп правильно. Какие-то особенные грабли на которые вы, видимо, намекаете, мне как-то не попадались.

A>Причем для интеропа clr-com такой стек будет совершенно не информативным в плане расследования проблемы.
A>Нужен человек, который как минимум понимает чем отличается 6BA от 6BE.

Если под "мы видим тока библиотеки CLR времени исполнения дотнета" ТС подразумевал что-то типа

mscorlib_ni+0x2f2bbb
mscorlib_ni+0x3675d1
mscorlib_ni+0x36740f

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

отвечу сразу как бы на весь этот subthread разговора.

Да, вы видим, чтото типа
mscorlib_ni+0x2f2bbb
mscorlib_ni+0x3675d1
mscorlib_ni+0x36740f

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

Нет — WinDBG даже и не думали юзать — ибо на кой ляд тогда в купленной студии существует свой
дебаггер? С С++ кодом, что нам надо — он отлично справляется. И с дампами кода на основе С++ тоже.
Так что чем он ТАК принципиально отличается от WinDBG — что вы предлагаете юзать его при отладке
managed кода?