Comments 4
Буду первым кто спросит у автора данной статьи.
Я изучаю как работают исключения под C++ + C++/clr + C#, с намерением обрабатывать ошибки со всех этих языковых диалектов. На данный момент я уже кое-что описал что и как работает здесь:
github.com/dotnet/diagnostics/issues/152#issuecomment-616082922
и мне интересно если у меня имеется C# аппликация, которая использует C++ — как исключения обрабавываются там. Как упоминается в моем сообщении — ни SetUnhandledExceptionFilter, ни AddVectoredExceptionHandler в C# аппликации не дают полного контроля над C++ exception (пытаюсь валить код по записи на invalid pointer).
Но тем не менее C# аппликация вызывает AppDomain.CurrentDomain.UnhandledException на стороне C#, но это уже немного поздновато, так как UnhandledExceptionEventArgs.IsTerminating = true и остановить падение программы уже невозможно.
Тем не менее — я заметил что вызов C# кода проиходит с vcruntime140_clr0400.dll / __C_specific_handler.
Я могу туда даже поверить hook, изпользуя minhook библиотеку. Но у меня остается вопрос что при вызове данной функции делать. и не слишком ли это поздно уже.
В данной статье:
web.archive.org/web/20080213085805/http://msdn.microsoft.com/msdnmag/issues/01/09/hood/default.aspx
Some tools (such as Mutek's BugTrapper) have circumvented this problem by overwriting parts of the user mode exception handling code in NTDLL. One place to do this would be the KiUserExceptionDispatcher function in NTDLL.DLL, which I described in the aforementioned structured exception handling article in MSJ. While overwriting KiUserExceptionDispatcher works, it's a fragile solution, and prone to breaking as new versions of NTDLL come out.
Упоминается возможность вешать hook на NTDLL, но как я понял — это тоже проблематично, как как NTDLL имеет одну копию не дупликаты per процесс как например с kernel32.dll. Но в принципе это не важно, так как NTDLL вызывает vcruntime140_clr0400.dll, куда мы можем повесить hook.
Я попытался найти что можно делать вообще в функции __C_specific_handler, и нашёл Wine имплементацию оного
www.winehq.org/pipermail/wine-cvs/2009-May/055617.html
который в принципе предлагает стратегию обработки данной функции, но уверен сработает ли он с managed code и во всех случаях.
Здесь очень бы помог сам код vcruntime140_clr0400.dll, вроде как не существует как open source code.
Может можете что посоветовать?
Я изучаю как работают исключения под C++ + C++/clr + C#, с намерением обрабатывать ошибки со всех этих языковых диалектов. На данный момент я уже кое-что описал что и как работает здесь:
github.com/dotnet/diagnostics/issues/152#issuecomment-616082922
и мне интересно если у меня имеется C# аппликация, которая использует C++ — как исключения обрабавываются там. Как упоминается в моем сообщении — ни SetUnhandledExceptionFilter, ни AddVectoredExceptionHandler в C# аппликации не дают полного контроля над C++ exception (пытаюсь валить код по записи на invalid pointer).
Но тем не менее C# аппликация вызывает AppDomain.CurrentDomain.UnhandledException на стороне C#, но это уже немного поздновато, так как UnhandledExceptionEventArgs.IsTerminating = true и остановить падение программы уже невозможно.
Тем не менее — я заметил что вызов C# кода проиходит с vcruntime140_clr0400.dll / __C_specific_handler.
Я могу туда даже поверить hook, изпользуя minhook библиотеку. Но у меня остается вопрос что при вызове данной функции делать. и не слишком ли это поздно уже.
В данной статье:
web.archive.org/web/20080213085805/http://msdn.microsoft.com/msdnmag/issues/01/09/hood/default.aspx
Some tools (such as Mutek's BugTrapper) have circumvented this problem by overwriting parts of the user mode exception handling code in NTDLL. One place to do this would be the KiUserExceptionDispatcher function in NTDLL.DLL, which I described in the aforementioned structured exception handling article in MSJ. While overwriting KiUserExceptionDispatcher works, it's a fragile solution, and prone to breaking as new versions of NTDLL come out.
Упоминается возможность вешать hook на NTDLL, но как я понял — это тоже проблематично, как как NTDLL имеет одну копию не дупликаты per процесс как например с kernel32.dll. Но в принципе это не важно, так как NTDLL вызывает vcruntime140_clr0400.dll, куда мы можем повесить hook.
Я попытался найти что можно делать вообще в функции __C_specific_handler, и нашёл Wine имплементацию оного
www.winehq.org/pipermail/wine-cvs/2009-May/055617.html
который в принципе предлагает стратегию обработки данной функции, но уверен сработает ли он с managed code и во всех случаях.
Здесь очень бы помог сам код vcruntime140_clr0400.dll, вроде как не существует как open source code.
Может можете что посоветовать?
Некоторых вещей, которые вы приводите, я не касался. Все что вы сделали, подтолкнули меня на изучения дополнительного материала. Ответить вам — я не готов. У меня не было опыта по некоторым вопросам.
В общем пока вы отвечали, я уже умудрился интегрировать свой код в boost / stacktrace библиотеку.
На данный момент то, что я сделал и/или собираюсь сделать описанно тут:
github.com/dotnet/runtime/issues/12405#issuecomment-626291059
А сам обработчик исключений находится тут:
github.com/tapika/stacktrace
см. example — csharp_crashy_window.xaml.cs / cpp_crashy_managed_dll/cpp_crashy_managed_dll.cpp
Пока что очень на эксперементальном уровне, но я могу теперь нативные падения отлавливать и передевывать в managed их. С достанавием call stackа и прочего.
Но пока что библиотека не допилена до конца, надо будет добавить managed call stack determination, и прочее.
На данный момент то, что я сделал и/или собираюсь сделать описанно тут:
github.com/dotnet/runtime/issues/12405#issuecomment-626291059
А сам обработчик исключений находится тут:
github.com/tapika/stacktrace
см. example — csharp_crashy_window.xaml.cs / cpp_crashy_managed_dll/cpp_crashy_managed_dll.cpp
Пока что очень на эксперементальном уровне, но я могу теперь нативные падения отлавливать и передевывать в managed их. С достанавием call stackа и прочего.
Но пока что библиотека не допилена до конца, надо будет добавить managed call stack determination, и прочее.
Кстати — то что я пробовал 32/64-битные аппликации — в 32-битной версии все по другому чем в 64-битном. вот один из коммиттов что я закоммитил:
github.com/boostorg/stacktrace/pull/90/commits/cf4eb6300c1d19b8fe0138bbd275b69a9b36de80
Я повесил hook на __CxxFrameHandler3, но он работает только с native code exception, но не с managed code exception, так что пока что отключил все относящееся к 32битному коду. Пока оставлю как есть потом может вернусь к этому коду.
Вообще 32/64 отличаются в корне друг от друга.
Но то что я дебагирровал до данного момента — подвисание дебаггера, легкое или конкретное — это нормально. Отсутствие полного call stacka в дабаггере, (нужно пользовать process hacker), отличие работы аппликации с дебаггером или без него — это все нормально.
несраватывание debug breakpointов…
Ощущение что идешь в лес по дрова… :-) При чем дров больше чем самого леса…
github.com/dotnet/diagnostics/issues/152#issuecomment-480457800
> Some of our team's past efforts with C/C++ exception handling interop demonstrated this can > be extremely complicated and the amount of effort it took us to maintain it wasn't justified
> relative to the value it was delivering for .NET customers.
Интересно у людей с Микрософт те же проблемы что у меня?
:-)
github.com/boostorg/stacktrace/pull/90/commits/cf4eb6300c1d19b8fe0138bbd275b69a9b36de80
Я повесил hook на __CxxFrameHandler3, но он работает только с native code exception, но не с managed code exception, так что пока что отключил все относящееся к 32битному коду. Пока оставлю как есть потом может вернусь к этому коду.
Вообще 32/64 отличаются в корне друг от друга.
Но то что я дебагирровал до данного момента — подвисание дебаггера, легкое или конкретное — это нормально. Отсутствие полного call stacka в дабаггере, (нужно пользовать process hacker), отличие работы аппликации с дебаггером или без него — это все нормально.
несраватывание debug breakpointов…
Ощущение что идешь в лес по дрова… :-) При чем дров больше чем самого леса…
github.com/dotnet/diagnostics/issues/152#issuecomment-480457800
> Some of our team's past efforts with C/C++ exception handling interop demonstrated this can > be extremely complicated and the amount of effort it took us to maintain it wasn't justified
> relative to the value it was delivering for .NET customers.
Интересно у людей с Микрософт те же проблемы что у меня?
:-)
Sign up to leave a comment.
Исключения в Windows x64. Как это работает. Часть 4