Recently I started working on VS2012.
When I debug my code (this is a SharePoint 2013 application) and trying to get the value of variables - I get again and again the message:
Function evaluation disabled because a previous function evaluation timed out.
You must continue execution to reenable function evaluation.
I previously worked in visual studio 2010 (for SharePoint 2010 applications) and almost never got this message while trying to get the value of variables in the Quick Watch.
I Googled the error message, and I saw that the problem occurs when trying to get a value of functions whose action takes a long time,
But I'm not trying to get a value of functions, only variables, and yet I get this error.
I do not always get the error on the same variables, but random - each time different variables.
Is anyone else having this problem specifically in VS2012?
And how can I get rid of it?
Why this is happening ?
It seems this kind of bug can happen simply when you are trying to watch at some variables who have to be thread safe but sometimes this framework implementation is not perfect....
To avoid this problem : when stepping through code where variables are bound to windows or other controls, you don't show local variables or "auto" variables. Look at such things only when you are sure your variables are all safe to look at. And note that the error doesn't necessarily appear on the unsafe variables. Use the "immediate" window on safe (i.e. non-control) variables when operating in dangerous code.
Data accessors should always be thread safe. But sometimes between two implementations (let's say between Sharepoint 2010 and Sharepoint 2012 or two version of the .NET framework), this rules is sometimes not true... There is some examples between VS2003 and 2005...
How can I increase the timeout ?
You can increase the timeout by changing the values of the registry Key HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\Debugger using RegEdit.
Don't forget to restart Visual Studio after changing the registry key.
Related
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 have a Visual Basic 4 32 bit application which results in a
Run-time error '5':
Invalid procedure call
I start WinDbg and do
sxe *
to break on all exceptions. However, it displays the message without breaking into the debugger before.
If I break at the time of the message, the callstack is not very useful. Is there a trick to break-in on Visual Basic 4 applications at the time the problem occurs?
Problem FAQ:
Can you run it in the IDE?
Yes I can and I can probably fix the bug when I do that. However, I'd like to get some more information at the time the end user runs the application so that I don't need to be able to reproduce it.
What do you want to do in case you find the cause of the error?
Well, it depends on the type of the error. Maybe I can fix it, maybe I can't. Usually I get some very helpful information out of WinDbg.
When does the error occur?
It occurs reproducibly when the user presses a close button on a form.
What does the application do?
Oh, that's a good question. I don't exactly know. It uses RS232 communication but it's not yet involved.
Do you know anything about the data the user can enter?
I almost know nothing about it. In this particular case, it's not necessary to enter data.
The error is from the VB virtual machine not from an API.
I can't see how WinDbg would be useful on VB4 which is interpreted and is in P-Code.
Visual Basic run-time error 5 Indicates one of the following:
An invalid collection or property name was entered.
An out parameter was NULL.
The value is not one of the supported values or falls outside the supported range.
The property is read-only.
The property cannot be changed after the object is created.
An invalid index was entered.
And in case it's an API call VB uses LoadLibrary and GetProcAddress.
Some controls have lost default values over time and this can cause the first.
The third can happen if modern technology exceeds the program's expection, e.g. disk space.
Also see (sorry no links, they are on my hard disk)
Q131007 HOWTO: Use Windows NT WinDbg.exe with Visual Basic (it's for NT 3.5)
Q166275 HOWTO: Debug a Native Code Visual Basic Component in VC++ (talks about what you can see in VB in a debugger)
VB4 can't make symbols
As the error occurs when the users presses the close button i assume there is a (very tight) loop running which doesn't receive the expected data (probably a nullstring)
I expect that that loop is continuously reading data from the RS232 device and the RS232 is on the form which is being closed, even though it is not involved the connection might already be open and polling
What you should do is exit that loop and close the connection with the RS232 device before closing the form. You might be able to do that in the Form_Unload() event, but it might also have to take place before that, so you might have to do it in the code of the close button ... make sure though that the user won't be using the X to close the form though
Personally i would run the program from within the IDE, this will point you to the errornous part of the code directly and gives you the opportunity to watch the contents of the variables involved and control states ... that is much faster than taking a guess based on the data of WinDbg
I really need to figure out when my Fortran project is reading an element of a vector. I use data breakpoint on a daily basis but I could not find a way to set a data breakpoint when my code access (i.e. read) a memory address, while I always set it for breaking when the address is modified. Is there a way to do this on Visual Studio 2010? (I use intel visual fortran compose XE 2011 as compiler). Or maybe updating to a more recent visual studio?
Just as a note, I saw here that gdb does that Can I set a breakpoint on 'memory access' in GDB?
thanks
A.
Ps: I emaild the guys from GDB and they said its not possible to do it with it.See their answer below:
Hello,
Currently the type of created watchpoint is hardcoded to "write". This is because
Visual Studio has no support for other types of watchpoints (in GUI and infrastructure).
Perhaps it would be possible to enable read watchpoints in the GDB console,
however it also would require a hack, as the console actually works "through"
Visual Studio (it does not pass commands directly to GDB).
I am also not sure whether this feature really works in GDB. GDB has a lot
of commands which have very limited target scope, e.g. they only work
for single threaded programs, or just for Linux and not when using
gdbserver, etc. A read watchpoint looks like a mechanism that is very
platform dependent. Please check if GDB your platform supports read watchpoints.
Also let us know if this feature is critical for you.
Best regards
Some workarounds (except using WinDBG):
Inject a NaN value if it is about a floating point element. And enable trapping of operations with NaN. This will catch not a read, but a first arithmetic operation with the value. Thus copying of the element will be missed, but an attempt to perform an operation will throw an FP exception exposing the place it occurs.
Unmap a memory page with the value. It's very unexact and will react for access to 4Kb of data around the value... But it still may work for some cases. Check description of MapUserPhysicalPages() for Windows, and munmap() for Linux.
You can use Mike Morearty's Hardware Breakpoints.
I have not tested them on Visual Studio 2010, but I have succesfully used it in VS 2008, 2015 and 2017.
int x = 0;
HardwareBreakpoint hb;
hb.Set(&x, sizeof(x), HardwareBreakpoint::Read);
// Some random code.
int y = x; // The breakpoint pauses the execution on this line.
Note that HardwareBreakpoint object must be in the scope while you want that breakpoint to be alive. When it goes out of the scope, the breakpoint will stop functioning.
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! :) )
I have a VB app that I need to monitor while it is running. I added some variables to the Watch window, but while the app is running the watch window is greyed out. The only way that I have found to see the variable values is to use Debug -> Break All, but this stops the program.
I have used other IDEs and they allow active variables to be monitored. Is this possible in VS?
Sorry if this is a noob question.
UPDATE: To be clear, my app is communicating with a piece of lab equipment and and as data is sent or received or errors are detected counters are incremented. I would like to watch these counters but I don't want to build a screen to do this since they are for debugging. I just assumed that this is basic functionality in any IDE
SHOCKED: It seems that Visual Studio does not offer this (what I would consider) basic functionality. For those that seem to think that this is not possible with an interpreted language, consider this thought experiment. If you pressed Break All quickly followed by a Continue then you would refresh the watch window - correct? Why then can't Visual Studio do this as a single Refresh Watch command or better yet allow this function to automatically run at a period specified by the user. No debug writes, no log files, no stopping your program mid-stream and creating timeouts. I am just shocked that you cannot do this. Its a little like not having breakpoints.
Which IDE or development environment shows - in real time - the values of variables in the Watch window, without having to hit any breakpoints, while the application is running?
Visual Studio doesn't provide this. In order to get updated values in the Watch window, or edit items there, the app needs to be at a breakpoint or debugging.
After you've done "break" to give control of the program to the debugger, then you can "step" through the code using function keys like F10 and F11. During each 'step', the program evaluates one or more statements; after each step it stops (until the next step), and while (only while) it's stopped you can 'watch' its current state.
There are other ways too to break into the debugger (to use the Watch window while the program is stopped): other ways like to set 'breakpoints', and use the 'run to cursor' feature.
Of course, but stopping a program that is actively receiving or sending data to a some other process, driver, etc, stops this communication and causes timeouts and other problems.
That's true. To watch values change in real-time, I use a log file:
Add statements to my code, such that when I change the value of a variable I emit a new line to a log file (showing the changed value)
Run the program
Watch new lines being appended to the log file using a utility like tail -f.
I've never see a debugger with the functionality you mention. The closest thing to the functionality you mentioned (and which isn't exactly the functionality you mentioned) is How to: Set a Data Breakpoint (Native Only).
What you're attempting to do is not possible in Visual Studio. All of the variable inspection windows (watch, locals, autos, etc ...) rely on the debugee process being in a break state in order to function.
This is true of essentially any debugger I've worked with in the past. At least those which use a compiled language.
I'm curious as to what IDE's you're referring to? Did they deal with interpreted languages?
Make sure you are in "Debug" build and Microsoft Debugger is running as a service and not blocked/disabled.
This should help you: How to trace and debug in Visual C++ .NET and in Visual C++ 2005
my 88 year old memory remembers an old version of visual studio allowing a watch window to function while debugging.
OK, just me.