I'm writing a class in C++ that I cannot debug by using F5. The code will run from another "service" that will invoke it.
In the past I've used __debugbreak() and when I got a window telling me that an exception was thrown selected to debug it.
Recently I've updated to windows 7 and it kept working for a while.
Today when I've tried to debug a piece of my code instead of shown the regular dialog that tells me that VSTestHost has stopped working and enable me to to debug the application I got a different dialog suggesting I send the data to microsoft for analysis.
Does anyone knows how can I fix this issue so I'll be able to debug my code?
Finally I found the cause of the issue.
It's a Vista/Win7 cause:
Open The Action center control
Goto Action Center settings
Goto Problem Reporting Settings
Choose "Each time a problem occurs, ask me before checking for solution"
Although this is more of IT solution/question I've been plagued with this problem all day and wanted to share the solution with other developers who encounter this problem.
I finally found the solution for Windows 10/11 here:
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/enabling-postmortem-debugging
And also: https://learn.microsoft.com/en-us/windows/desktop/Debug/configuring-automatic-debugging
To enable automatic debugger launch, you should add a registry value:
key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug, value Auto = 1 (of type REG_DWORD)
The configured debugger is set the by the value Debugger (type REG_SZ); a Visual Studio installation sets this to:
"C:\WINDOWS\system32\vsjitdebugger.exe" -p %ld -e %ld
Note that on 64 bit OS this only works for 64 bit executables. To enable the same behaviour in 32 bit executables set the same values in this key:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug
In that case...
http://community.codesmithtools.com/blogs/blake/archive/2009/06/03/tips-amp-tricks-debugging-codesmith-on-microsoft-windows-7.aspx
Here is the quick overview of what you need to-do to enable debugging on a Microsoft Windows 7 machine:
Update the Just-In-Time debugger setting DbgJITDebugLaunchSetting. The setting is found in the registry at [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework].
Set the value of DbgJITDebugLaunchSetting to 2.
If you are using a 64bit operating system then you must also set the same key (DbgJITDebugLaunchSetting) in this folder [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework] to 2.
If you run into any issues try running CodeSmith Studio and Visual Studio as an administrator.
Now when CodeSmith enters a break point you will see something like this:
You could try debug > attach to process.
Related
I see the following error whenever I try to debug "Cross Platform" under "C++" category: "Unable to start debugging. Unexpected GDB output from command "-target-select remote :5039". Remote connection closed"
I've installed all of the contents when I downloaded Visual Studio 2015 community and I ran it on Windows 10 Pro which supports Hyper-V.
I've been searching a solution for this and I've found an assumption:
"What is your debug target, the VS Android Emulator? When we saw this before it turned out to be a bad emulator image. Do you have this problem with all targets (e.g. if you try a physical device) or just one?"
In my case, I just tried this via Emulator(VS Emulator 5" Lolipop (5.0) XXHDP Phone (0x86 -...)
So I've sent an Email to VS 2015.
And the answer was like this:
"Sorry for the delay in responding we were looking at an emulator image of another user that ran into this problem so I was waiting until we had the results of that investigation to report back. We actually were not able to find anything wrong the emulator itself, our current hypothesis is that it is a network or adb problem interfering with GDB’s ability to connect to GDB server on the remote machine. Do you see this error every time you try to debug, or if you reboot the emulator will it work sometimes right after the reboot? Next time you see the error, can you open the emulator’s console mode by going go the Hyper-V manager and double clicking the emulator. Then find the location your app installed to and run “gdbserver --version" from the app path and let me know what it says? This will validate if the correct version of gdbserver is on the device."
So we are trying to solve this problem but I'm also asking here just in case.
Is there anyone who has magical solution for this problem?
I'll put a comment on this if I figure out how to solve this.
Thanks in advance.
** Following answer is from the manager of Visual Studio 2015:
You are only the second person who has run into this issue, and the first person that ran into it provided their everything works correctly when we run their .vhd on our machines so it appears to be some strange problem where gdbserver (which comes from the Android NDK provided by Google) crashes only when running on certain machines. Unfortunately the .vhd you provided does not appear to be the correct one it won’t boot for me. You can see the .vhd file being used by the emulator if you look under the settings of the emulator in your Hyper-V manager. .However given we got the other person’s .vhd you can hold off providing any additional information at this point. I’m waiting to hear back from the emulator team on if they have any ideas since this appears to be an issue only on specific machines since.
If you don’t mind my asking, if you don’t have a background in computers what inspired you to try C++ on Android? That scenario will be significantly more complicated than doing Java on Android.
It's been almost two months since I got this answer but I haven't got any additional response from them yet. So, I ended up quitting developing an application by using VS2015.
If you run into this problem, there are only two ways to go. Change your computer or stop developing application via VS2015.
If the project name contains spaces, the whole remote debugging fails. Visual Studio also creates weird paths. When checking out the "Blink1 for Raspberry Pi" template, I named the Project "Blink1 for Pi", which resulted in a path like this:
~/projects/Blink1?/for/pi/PI/for/pi....
And all the debugging failed. When I recreated this keeping the project name "Blink1", everything worked fine. It's a pity, that spaces aren't handled here...
Trying to launch the editor from Visual Studio 2013 Ultimate I get the following error in the title. VS says it's because it can't reach MSVSMON.EXE on a "remote computer", the weird thing is that I'm not trying to debug on a remote computer, but rather, on my own. My firewall is ZoneAlarm if that makes any difference.
Any help?
Edit: I've set all in and outbound communication to and from both unreal and visual studio in my firewall to "allowed", yet for some reason it still won't let me debug...
Edit 2: Disabling the firewall entirely does nothing at all.. The error persists
Edit 3: Uninstalling ZA altogether seems to fix the issue
Just a note, so far you've been chasing the wrong problem and have not yet gathered enough relevant facts. The dialog is very unhelpful, this does not have anything to do with a "remote computer".
Msvsmon.exe is used in this scenario because UE4Editor.exe is a 64-bit process. Visual Studio cannot use its built-in debugger, it is a 32-bit process. Debugging a 64-bit process with a 32-bit debugger is not possible. So it has a workaround, it uses the 64-bit remote debugger, C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe. Basically works the same has remote debugging on another machine, except it doesn't use the network to connect to the debugger.
So your firewall settings and the considerable amount of trouble-shooting info about remote debugging you can find on the web or MSDN just does not apply in your case at all. You've been chasing the wrong problem.
Having an issue with msvsmon.exe when debugging 64-bit code is quite unusual, never heard of anybody having trouble with it before. You want to do a basic smoke test to check if it is really a problem with msvsmon.exe or it is actually UE4Editor.exe that puts up a fight.
Create a little do-nothing C# console mode app, just Console.ReadLine() in the Main() method. Project + Properties, Build tab, untick the "Prefer 32-bit" option. This ensures it runs as a 64-bit process. Press F5. If all is well then it starts running and you'll see msvsmon.exe in the Task Manager, Processes tab.
If that does not work either then something is interfering with the process interop between Visual Studio and msvsmon.exe. Usually anti-malware related, disable that first. Next thing to try is to start killing processes one-by-one with Task Manager to find the evil-doer. If debugging the C# app works okay then you have a good reason to visit the UE4 forum to find help.
Update your question with what you've learned.
Uninstall Zone Alarm and everything will be OK.
I'm trying to debug shell extension (IContextMenu) in Windows 7 with Visual C++ 2008. I have set DesktopProcess=1 in the registry and set host app to explorer.exe. But when I start the debugger, it launches explorer.exe and then detaches from the process. DllMain of the shell extension isn't called.
The same code with exactly the same settings launched in debugger without any problems in Windows XP + Visual C++ 2008.
Any thoughts how to debug the shell extension in Win7?
I've found a nice workflow that I think is the fastest way to rapidly iterate the code-build-test cycle when developing shell extensions. The following should work on any Windows version.
First prepare - set the start program of your shell extension project to be c:\windows\explorer.exe and also set it to be the start-up project.
Then, whenever you want to debug your shell extension perform the following steps:
Click on the task bar and press Alt-F4 - this will bring up the shut down dialog
Press Ctrl-Alt-Shift-Escape - this combination will close explorer.
Use Alt-Tab to go back to Visual Studio and press F5 - explorer will now launch with the VS debugger attached to it from the very beginning.
When done, just stop the debugger session. This will kill the debugged instance of explorer and will also automatically start a normal instance of it. This will also unlock the shell extension DLL so that you can build it again.
Caveat on Vista and 7 - be sure to run the Visual Studio that you use for debugging in non-Administrator mode (non-elevated), so that the explorer is started in its usual non-elevated mode.
Try launching explorer and THEN attaching the debugger to it.
You could try putting a DebugBreak() call in your code. This should launch the just-in-time debugger at the call and give you an idea of what is going on.
You should take a look at gflags.exe, part of the standard debugging tools sdk. It's got all the options you need to configure (global)flags for any process startup/services/heap/pool-tagging/stacktrace's-on-allocation etc...
Debugging Explorer.exe is usually overkill for extensions that operate in a shell view.
I personally use a little app I made that hosts an instance of IExplorerBrowser similar to this example. If your IContextMenu item is not the default item then you can just use Notepad.exe and its open file dialog...
I've just discovered that regtlib.exe appears to be missing from Windows 7 (and apparently from Vista as well).
I've just installed Windows 7 RC in a VM and I'm attempting to build our existing projects on the new OS. The projects are c/c++ based and I'm using visual studio 2008. In order to build these projects I need to register several tlb files that are referenced within the code base.
Has anyone also encountered this problem? And, has anyone managed to solve this?
Thanks.
Yeah regtlib was removed from vista and up. As far as I know, all it does is call LoadTypeLibEx with the REGKIND_REGISTER flag (http://msdn.microsoft.com/en-us/library/ms221249.aspx). Maybe you could write a simple replacement.
Just came across this issue (couldn't add any components to a VB6 project on Win7). This post (Error accessing the system registry in VB 6 IDE) pointed to regtlib (which is missing from Win7). I just
set the VB6 start menu icon to 'Run As Administrator' and it worked fine for adding components and should fix any problems relating to updating the registry as well.
Regards
Ian
Finally got back to trying to build our code base on windows 7. Anyway, I went back to the installer for one of the dependencies that was causing me grief. The error message from the installer wasn't to helpful but it did point to a regasm that was being run from inside the installer.
I ran the regasm command from a cmd prompt and got more information. It appears that you need administrative credentials to perform this task and our current installers don't do the privilege escalation properly.
So, long story short, I got dlls registered and the build appears to be working.
I am using Hudson as a continuous integration server to test C/C++ code. Unfortunatly, I have a bug somewhere that causes memory corruption, so on some Windows machines I will sometimes get a "Application Error" dialog box explaining that an instruction referenced memory that could not be read. This dialog box pops up and basically hangs the test run, as it requires manual intervention.
Is there a way to prevent this dialog box from appearing, so that the test run simply fails and is reported as such in Hudson?
Is it possible to automatically generate a minidump instead of showing the dialog?
Use "Disable error reporting", as Mr. Gently suggests. See also this PC World article.
If you happen to have MS Visual Studio on your build machine, it will catch Application Errors and pop up a dialog box. To disable these dialogs (and also the Just-In-Time Debugging feature of Visual Studio), run the command drwtsn32.exe -i to set Dr. Watson as the default system debugger. Dr. Watson will generate a core dump and silently exit. (See this Microsoft Knowledge Base article: http://support.microsoft.com/kb/q121434/.)
You can also do something like this programaticaly using SetErrorMode. See this article for more details.
A simple example of how to use it is to do the following:
SetErrorMode(GetErrorMode () | SEM_NOGPFAULTERRORBOX);
The above 'ORs' the current mode with our desired addition.
In addition to what rkb said, if you are running Windows XP 64bit, there are two sets of values. The ones in the usual registry location and the ones under the Wow6432Node key in HKLM. In order to update both, run drwtsn32.exe -i from both %SYSTEMROOT%\system32 and %SYSTEMROOT%\SysWOW64.
Disable error reporting via:
Registry editing -- add your application to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting\ExclusionList, OR
Right-Click on My Computer, go to the Advanced Tab, and choose the "Disable error reporting" option, OR
You can navigate to the services console in Administrative tools, find the Error Reporting Service, go into properties and disable it
You can use the various _CrtSetReport functions to control the way the C/C++ runtime responds to various errors (_CrtSetReportHook, _CrtSetReportMode, _CrtSetReportFile, _CrtSetReportHook2)
Use a try/catch statement to catch the exception and handle it the way you want.