I am looking for code or options to disable a run time error. Instead showing that stupid message I just want a crash or to just continue. So in conclusion to do no show that message.
This question (or at least a very similar one) has been answered in Disable Microsoft Visual C Runtime Error
The errors need to be handled within your program to stop things going out of your control and the Microsoft dialog being displayed. The answer referred to explains how to capture these errors yourself. One way of implementing crash handling is to capture the minidumps for yourself, using something like CrashRpt into your software.
Related
I'm currently migranting an VBA powerpoint add-in to VSTO.
For weeks I've been struggling with Visual studio degug for COM objescts. AS you can see on the image below, the object types show {system._ComObject} and object inspection becomes a challenge since one must use the dynamic view, which is quite inconvenient in my opinion.
Looking around I've found a recommendation to activate the option "use managed code compatibility mode" in the general debugging settings, as you can see on Debugging setting
I also followed another the recommendation to set the property "Embed interop Types" on all my office related references to false.
After applying these changes. Voilà! The inspection began do work just as I wished to and as you can see here: Debug working properly
I was almost in heaven. My ecstasy lasted till I tried to change some code during debug and was informed by visual studio that
"managed compatibility mode does not support edit and continue".
Now I'm back in hell. With edit and continue I miss a decent COM object inspection. With COM inspection I cannot change code during debug.
This situation looks awkward and I would expect more from VS 2017.
Does anybody know how can I get decent COM inspection and edit and continue at the same time?
Does anybody know how can I get decent COM inspection and edit and
continue at the same time?
I am afraid that you cannnot get what you want.
Since you just debug a com object which is more like optimized, mixed, or SQL Server common language runtime (CLR) integration code(use ), as the official document said, Edit and Continue function does not support it.
Usually, to debug those mixed codes in VS, you should enable Use Managed Compatibility Mode or enable native code debugging, but those options cannot work well with Edit and Continue as the official document said.
You can check this document to know unsupported changes or supported changes to code.
So for your issue, there is no such option to use both of them.
As a suggestion, you should break the debugging process first, make some changes to your code. Then start Debugging to debug the new changes.
Besides, if you still want this feature, you could suggest a feature on our User Voice Forum. The Team will check your request carefully and hope they will give you a satisfactory reply.
I'm developing with Qt. Following a tiny change my program now will not start up and if I run the debugger, this dialog box is displayed:
I have looked at several other answers to questions about this error and Qt, and they all propose using a different compiler or a different version. I don't believe this will solve my problem.
Searching a little more diligently on Google, I came upon this article, about Visual C++ which suggests, very plausibly, that additional information is available but has been swallowed by one of the tools somewhere. The article goes on to suggest that by changing something in the registry, you can get additional information output when the error occurs. Now, I can run my program from the command line, with minimal intervening tools, so this looked like a really useful idea. Sadly, the link in the article that I believe will tell me more about the required registry change is dead.
Does this ring any bells with anyone? How can I found out the dll and entry point that isn't being found?
Thanks to helpful comments, I managed to get the additional trace enabled using the "image files" tab of gflags.exe. I then found an enormous quantity of trace information on the "Debugger Log" tab of the QCreator debugger.
Close examination showed that the function containing the tiny chnge which kicked off this problem was failing to load.
I have no idea what caused this, but a clean rebuild of the program in question now allows it to run to the point of the original failure that made me want to make a tiny change in the first place.
I guess the moral of the story is to do a clean build immediately when things start getting weird - before trying to pin down the weirdness!
I'm trying to do dump analysis using Visual Studio Professional 2017, but when entering the command .natvisreload in the watch-window I get syntax error and there is nothing in the output window. (This seems to mean that the command is not understood)
In order to get me on track of the real problem, I'd like to know an example of another command I can launch in the Watch window: does anybody know another command, starting with a dot, I can launch in the Watch window (in order to distinguish whether the issue is related to the specific command .natvisreload or to the general Watch window)?
"natvis" is an abbreviation for "native visualizer". Used by the unmanaged debugging engine to provide a customized view of a native object. The .natvisreload command is one that only the unmanaged debugging engine can understand. From the comment it is somewhat obvious how this went wrong:
An example of the slug you see when you use File > Open > File to open a minidump for a process that uses managed code. Note the 3 options you have at the upper right to get the debugging started. "Managed Only" only enables the managed debugging engine, "Native Only" for the unmanaged engine, "Mixed" enables both.
You used "Mixed". While that enables both engines, there can be only one active at the same time. Unfortunately it is not always obvious which particular one is in control. Other than the debugger being able to display source code. And a side effect like you discovered here, the ".natvisreload" command goes "huh?" since that is not a command that the managed debugging engine understands.
So one workaround is to use "Native Only".
You can however switch between engines on-the-fly. This normally happens automagically when the debugger lands on a breakpoint. Not an option for dump debugging. The non-intuitive other way is to use the Debug > Windows > Call Stack debugger window. In mixed-mode debugging you see both managed and unmanaged stack frames in the stack, starting with RtlUserThreadStart at the bottom. Double-click one of these frames, like the bottom one, and the debugger switches engines. Note that you don't necessarily have something decent to look at, especially if this was a managed program, and you merely get a machine code dump for the native code. The ".natvisreload" command will however now work as intended.
So when a program dies rather ungracefully, modern versions of Windows put up a dialog that reads:
Windows is searching for a solution to the problem
It clocks for a little while, then doesn't find anything. Well, I've never had it tell me it's found a solution.
The question is, what exactly is going on when this dialog is being shown? What are possible things it can show as "solutions"? Is there a way my application can tap into it?
Obviously, if I know enough about what could go wrong, I should handle it in the app, so I'm left wondering what this actually does.
Anyone know?
Windows Error Reporting is capturing a stack trace of the failed program and sending it off to Microsoft. The data it collects is stuffed into an enormous database for vendors to research; if this is your program, you can sign up here. If the vendor submits a patch, Windows will notify you.
You can tap into it, either by customizing the info, triggering reports for (soon to be) fatal errors, and much more.
M 8.0.1, windows 7.
A debugging question.
Sometimes when I start M and open my notebook (which has dynamics enabled in it before I closed it) I get this message
The problem is, no matter if I click on wait, or disable dynamics, the message keeps coming back.
I have to terminate the process itself (i.e. Mathematica) from windows task manager to get out of this.
Clearly I seem to have a bug somewhere in dynamics in my code.
My question is: Is there a way for M to tell me which dynamic objects is causing this problem? And any idea why telling it to disable dynamics updating is not helping here (as I keep getting the message).
thanks
You may have some luck by evaluating:
SetOptions[$FrontEnd, PrintKernelDynamicTraffic -> True]
This will cause the Mathematica FrontEnd to print messages to the system console (on Mac, I don't know where it goes on Windows) whenever it sends Dynamic evaluations to the kernel. If you can find the last Dynamic evaluation to print out when the message appears, that should be the one which is taking a long time to evaluate.
You'll probably want to disable this when you're done debugging so it doesn't fill your system log with millions of debug messages.
You may find DebugTrace, written by David Bailey, useful. It is a debugger which may also be used to debug dynamic constructions. In this documentation there is an example on how to debug such programs. Basically you set a breakpoint in your code, run it, and after it's done you are presented with detailed information on what happened when.
In general I highly recommend giving it a try, not only for the dynamic functionality.