Somehow I cannot view any debug-time windows. I select call stack from Debug-> Windows, but it is not shown anywhere. Same with Immediate.
You might want to try to reset your Visual Studio settings, see here or here.
Also, this post discusses several other commandline switches, reportedly for VS2012 but you can always try if they work for VS2010 as well.
Related
Every time I try to run my code, I am having this error: "Csc.exe" exited with code - 255.
I removed and re-installed Visual Studio 2015 and it did not help.
Does csc.exe succeed with different code?
It is possible that you’ve found a bug in the compiler that causes it to crash when trying to compile your particular program. To see if this is the case, create a new “Console App” project with Visual Studio (VS) and see if the default app in the template compiles and runs. If that works, then your code might be triggering a csc.exe crash. If that doesn’t work, your VS install might be completely broken in which case I would recommend uninstalling and reinstalling VS (but you already tried that). If you cannot get VS to run even simple programs on your computer, you’ll need to try to track down why it is crashing and see if it is something you can manually fix. If your system is messed up enough and it is not worth tracking a fix down, you might consider reinstalling Windows (using the “Reset” feature).
Another thing to try is running your code on another computer with VS installed. That can help determine if the issue is your code triggering a compiler error versus your computer being messed up.
If csc.exe only crashes for your particular code, then that is a bug in csc.exe. If there is an issue with your code, csc.exe should generate a nice error explaining the issue with your code instead of crashing.
It is also possible that your code is valid but a compiler bug causes csc.exe to crash. An example of this (with VS 2017 and csharp7) is roslyn#19182. If this is the case, you might try using the VS feedback (frowny face/feedback button in the upper right hand corner) feature to report the issue so that the VS developers know about it. Also, you might be able to poke your code around until suddenly VS starts running successfully. If this is the issue, it might be hard to guess why csc.exe is crashing, but, if you can, try to isolate the issue. For example, if csc.exe was running fine before you made some changes to your code, look at the changes you made and see if undoing them results in csc.exe running successfully again. Then try to make a new, minimal repro which causes csc.exe to crash and send that as feedback using VS’s feedback mechanism or by reporting a bug against the roslyn project. You might also ask a new question here about why that particular code causes csc.exe to crash. With particular code, people might be able to guess why csc.exe can’t handle it and suggest workarounds to use while waiting for the VS team to release a fix.
As it is, your question does not have enough information to guess why csc.exe was crashing for you. Hopefully this answer provides some guidance on what steps you should take if you ever end up in such a situation.
I have the following bug in a program:
An MDI MFC program closes silently on Windows 7 (terminates the process without prompting to save changes and without displaying any "crash" dialog) when the user performs this operation : Click a context menu item.
But this happens only on that PC, at least, for the moment. No other PC has encountered that problem. However the bug can always be reproduced following the same steps but only on that PC.
I want to know the reason but probably the customer won't allow me to install many programs to debug, so I need to be able to log when the program terminates, or print the stack in Release version but I'm quite lost.
I had faced a similar bug before and eventually I fixed it logging line by line and changing the problematic part, but I guess there are much better ways to find bug reasons than this.
I have tried on my development PC to create minidumps on Release mode but if there is no exception thrown on that PC, (I haven't confirmed that yet, though...) maybe it's pointless.
Also used an available class on codeproject (Stackwalker) but I don't manage to print all the function calls. Only on simple console programs, but not on MDI or even SDI.
Any ideas on how to find out the reason? Thanks in advance.
I am having serious trouble getting the JIT debugger event trigger when using the Stop statement on my scripts.
Me an 2 other coworkers have been doing research on the issue and none of us can figure out what is the problem. We have uninstalled and reinstalled Microsoft script editor, and we have updated the registry values, we have added ourselves to the debugger users group. We have admin rights etc.
Not using this debugger is not an option, is a project requirement but we cant get it to work on 2 of our machines. However, the team leads machine does work. but we have 2 machines that the debug event does not trigger. When comparing settings everything seems to be in order.
We have followed the instructions on MSDN and various other found around the web.
Is MDM.exe running in Task Manager? (it's a service, Machine Debug Manager).
cscript //x nameofscript.vbs work?
stumbled on this post one year after... hope in the meantime you found a solution.
I have too the problem when I need to JIT-Debug my VBS Scripts; I 've realized that the debugger won't fire up upon Stop statement but only in case an Exception is thrown; After you are in debug mode, then, Stop statements should work again, but you need to generate an exception in order to invoke the debugger.
When I need to break a VBScript, I usually put a call to a non-existing function in order to intentionally cause an ecxeption: this will trigger the debugger and I'm able to work with it.
Sample code:
(do something)
DEBUG_INVOKE ' Function DEBUG_INVOKE does not exist => Exception.
' you can actually type whatever you want, eg. 'stp', 'stopp', 'xxx', etc.
' provided, of course, it's NOT the name of a Sub or Function present in
' your script.
(do other stuff)
After you enter debug mode, then, you may not be able to move from break position: it depends on the debugger: I know, i.e. that MS Script Debugger and Visual Studio 2015 Community Ed. do like this, while MS Script Editor and Visual Studio 2010 Professional allow you to move the pointer and do step-by-step debugging. Still investigating on this!
HTH,
Max - Italy
I've been trying to use programmatic data breakpoints, à la the CBreakpoint example, by using SetThreadContext to set the debug register directly. Most references that I can find indicate the Visual Studio will still break whenever it encounters a data breakpoint, even if it didn't set that data breakpoint itself. However, this doesn't appear to be how Visual Studio 2010 works.
I'm in a situation where my data breakpoint works perfectly when the program is not being debugged (it crashes with STATUS_SINGLE_STEP, which is the exception raised by a data breakpoint). It also breaks properly if I'm debugging with WinDbg. But when debugging it under either Visual Studio 2010, it seems to just keep trucking and ignore the breakpoint. Does anyone have any experience with using a programmatically-set data breakpoint under Visual Studio 2010, under Windows 7? Is there something that I need to do to it them to break? (I tried adding STATUS_SINGLE_STEP to the 'first-chance exceptions' list, with no change in behavior.)
Alternately, is there anything that I might be doing to swallow the STATUS_SINGLE_STEP exception in the debugger? Would a structured exception handler eat the exception before the debugger can see it? Is anything affected by the fact that this is a x86_64 program? Is there some dance I need to do in the Visual Studio 2010 settings?
Did a little testing, got VS 2010 SP1 Ultimate on win7 x64, using a 32bit binary to break correctly on HW breakpoints (both with and without SEH). When using a 64 bit binary however, it doesn't trap the single step (and I had to alter a few types just to get it to compile).
Digging a little deeper, it seems to be VS acting weird, cause although it doesn't trap the single step, I can't get it to correctly step over a section of code that will trigger a HW breakpoint.
I have a feeling that the library isn't correctly setting the DR registers under x64, this may be to do changes in SetThreadContext for x64.
Update
Fiddling around a little more, I noticed that the library you are using doesn't suspend the thread before setting or getting the thread context, MSDN says this is a big NO-NO:
You cannot get a valid context for a running thread. Use the SuspendThread function to suspend the thread before calling GetThreadContext.
However, even using another library that does correctly suspend the target thread and executes all its calls without error still doesn't let VS trap the BP, which makes me think that not only is the library you are using buggy, but VS' x64 debugger is buggy as well.
Have you enabled mixed (native & managed) debugging for your project?
I went to project properties->configuration properties->debugger->debug type set to "mixed"
found this answer here:
https://social.msdn.microsoft.com/Forums/windowsserver/en-US/47ebd835-e538-4ff6-8c91-df45bd46d548/vc-express-2012-x64-clr-breakpoint-not-hit-no-executable-associated-static-library?forum=windbg
There is a function named DebugBreak() that you can use to programmatically break your execution under MSVC 2010 but it stop inside of DebugBreak( disassembly code ). So if you want to break just in your code use __asm int 3 this is very simple and work in all intel compatible CPUs.
And one other note use IsDebuggerPresent() before either of DebugBreak() or __asm int 3 to avoid error in runtime( of course you already know that! :) )
A known bug with a Windows XP security update KB978037 can occur with Visual Studio 2005 (and 2008) where sometimes if you restart a debugging session on a console app then the console window doesn't get closed even though the owner process no longer exists. The problem is discussed further here:
Visual studio debug console sometimes stays open and is impossible to close
These zombie windows then can not be closed via the Taskbar or via the TaskManager, and typically require a power off/on to get rid of them. Over the period of even a single day you can accumulate quite a few of them, which clog up your TaskBar and are generally annoying.
I thought I would knock up a simple C++ Win32 utility to attempt to call DestroyWindow() on these windows by passing the windows handle as a cmd-line argument and converting it to a HWND.
I'm converting the handle from a string by parsing it as a DWORD then casting the DWORD to a HWND. This appears to be working as if I call GetWindowInfo() on the handle it succeeds. However calling DestroyWindow() on the handle fails with error 5 (access denied), presumably because the caller process (i.e. my app) doesn't own the window in question.
Any ideas as to how I might get rid of the zombie windows, either via the above approach or any other alternative short of rebooting? I'm in a corporate environment so installing/uninstalling updates/service-packs etc isn't an option.
Microsoft's hot fix for Windows XP and Windows 2003
I know this is not what you want to hear but the only way to get rid of these windows is by rebooting the computer
Apparently the windows team is trying to fix it:
http://blogs.msdn.com/debugger/archive/2010/03/11/help-my-console-windows-won-t-go-away.aspx
but not much seems to be happening
This issue is still a problem with Visual Studio 2010 on Windows 7!
See this thread