I am currently using the Windows Error Reporting service that is built into the Windows OS. It falls short in quite a few areas including automating new builds being submitted for crash collection and analysis of the actual crashes.
我目前正在使用Windows操作系统内置的Windows错误报告服务。它涉及很多领域,包括自动提交用于崩溃收集的新构建和实际崩溃的分析。
I found a few options including Dr Dump and CrashRpt for C++ applications.
我找到了一些选项,包括Dr Dump和CrashRpt for C ++应用程序。
The most appealing option that I found though was HockeyApp. My team already uses HockeyApp for hosting mobile applications as well as builds of our desktop applications. Plus, it just seems more well-supported and feature-rich than other services. It seems to only support crash reports for .NET applications.
我发现最吸引人的选择是HockeyApp。我的团队已经使用HockeyApp来托管移动应用程序以及我们桌面应用程序的构建。此外,它似乎比其他服务更受支持和功能丰富。它似乎只支持.NET应用程序的崩溃报告。
The application that I am trying to gather crash reports for is a mixed C++ and C# application though. I'm not sure if there is a crash reporting service out there that can handle both languages.
我试图收集崩溃报告的应用程序是一个混合的C ++和C#应用程序。我不确定是否有可以处理这两种语言的崩溃报告服务。
Without going into immense detail, my application is mostly .NET wrapped up in a native C++ application. I'm assuming that this means I need a service to support C++ crash reporting.
在没有深入细节的情况下,我的应用程序主要是.NET包含在本机C ++应用程序中。我假设这意味着我需要一项服务来支持C ++崩溃报告。
To summarize:
- If my applications is mostly .NET based, but wrapped up in a native C++ appliaction, do I need a crash reporting service that just supports C++ applications?
- Is there a crash reporting service that supports applications with mixed C++ and C# code?
如果我的应用程序主要是基于.NET的,但是包含在本机C ++应用程序中,我是否需要一个仅支持C ++应用程序的崩溃报告服务?
是否有支持具有混合C ++和C#代码的应用程序的崩溃报告服务?
1 个解决方案
#1
0
Those tools have a disadvantage: they use the Unhandled Exception Handling mechanism and live in your process. If your application gets corrupted, maybe you no longer can rely on things to work. I had that case in VB6, where the VB6 runtime was destroyed and no unhandled exception handler could help me.
这些工具有一个缺点:它们使用Unhandled Exception Handling机制并在您的过程中生效。如果您的应用程序被破坏,也许您不再依赖于工作。我在VB6中有这种情况,其中VB6运行时被破坏,没有未处理的异常处理程序可以帮助我。
That's also why WER exists. While your process is dying, Windows itself still works pretty fine. And perhaps you can benefit from its features, too: the WER LocalDumps Registry Key
这也是WER存在的原因。虽然你的过程正在消亡,但Windows本身仍然运行良好。也许你也可以从它的功能中受益:WER LocalDumps注册表项
Set this Registry key during the installation of your product and it will save crash dumps into a folder. When your application starts up next time, you can do with them whatever you want (maybe ask for the user's permission):
在安装产品期间设置此注册表项,它会将崩溃转储保存到文件夹中。当您的应用程序下次启动时,您可以随意使用它们(可能需要用户的许可):
- analyze the crash dump (e.g. using ClrMd) and send some exception details to you
- shrink the crash dump and send the shrunken one to you. (Convert a full memory .NET dump into a small minidump)
- upon request ask the user to send the full crash dump to you
- don't forget some clean up
分析崩溃转储(例如使用ClrMd)并向您发送一些异常详细信息
缩小故障转储并将缩小的转发器发送给您。 (将完整内存.NET转储转换为小型小型转储)
根据要求,请求用户将完整的故障转储发送给您
不要忘了一些清理
All in all I would say it's not hard to do. Might be a good project for students. Pro: you don't need to care about all that crash handling, pointer mangling etc., because WER does it for you. You can't really mess it up.
总而言之,我会说这并不难。对学生来说可能是个好项目。亲:你不需要关心所有崩溃处理,指针修改等,因为WER会为你做。你真的搞不清楚了。
Oh, and when you build that, consider building it as a reusable component and make it open source on Github. I would need that, too. You can't get a patent any more, because with this post I will claim "prior art" :-)
哦,当你构建它时,考虑将它构建为可重用的组件,并在Github上将其作为开源。我也需要那个。你不能再获得专利,因为有了这篇文章,我将声称“现有技术”:-)
#1
0
Those tools have a disadvantage: they use the Unhandled Exception Handling mechanism and live in your process. If your application gets corrupted, maybe you no longer can rely on things to work. I had that case in VB6, where the VB6 runtime was destroyed and no unhandled exception handler could help me.
这些工具有一个缺点:它们使用Unhandled Exception Handling机制并在您的过程中生效。如果您的应用程序被破坏,也许您不再依赖于工作。我在VB6中有这种情况,其中VB6运行时被破坏,没有未处理的异常处理程序可以帮助我。
That's also why WER exists. While your process is dying, Windows itself still works pretty fine. And perhaps you can benefit from its features, too: the WER LocalDumps Registry Key
这也是WER存在的原因。虽然你的过程正在消亡,但Windows本身仍然运行良好。也许你也可以从它的功能中受益:WER LocalDumps注册表项
Set this Registry key during the installation of your product and it will save crash dumps into a folder. When your application starts up next time, you can do with them whatever you want (maybe ask for the user's permission):
在安装产品期间设置此注册表项,它会将崩溃转储保存到文件夹中。当您的应用程序下次启动时,您可以随意使用它们(可能需要用户的许可):
- analyze the crash dump (e.g. using ClrMd) and send some exception details to you
- shrink the crash dump and send the shrunken one to you. (Convert a full memory .NET dump into a small minidump)
- upon request ask the user to send the full crash dump to you
- don't forget some clean up
分析崩溃转储(例如使用ClrMd)并向您发送一些异常详细信息
缩小故障转储并将缩小的转发器发送给您。 (将完整内存.NET转储转换为小型小型转储)
根据要求,请求用户将完整的故障转储发送给您
不要忘了一些清理
All in all I would say it's not hard to do. Might be a good project for students. Pro: you don't need to care about all that crash handling, pointer mangling etc., because WER does it for you. You can't really mess it up.
总而言之,我会说这并不难。对学生来说可能是个好项目。亲:你不需要关心所有崩溃处理,指针修改等,因为WER会为你做。你真的搞不清楚了。
Oh, and when you build that, consider building it as a reusable component and make it open source on Github. I would need that, too. You can't get a patent any more, because with this post I will claim "prior art" :-)
哦,当你构建它时,考虑将它构建为可重用的组件,并在Github上将其作为开源。我也需要那个。你不能再获得专利,因为有了这篇文章,我将声称“现有技术”:-)