Basically my problem is that I expect Visual Studio (2010 Professional) to be able to evaluate any Visual C++ expression in the watch window that it handles in the code I'm debugging, but apparently there's something preventing this from happening. For example, when dealing with CStrings, evaluating the method IsEmpty on the CString in the watch window gives me a Member function not found error, as does a basic equality comparison (in the code being debugged obviously no problems).
Am I missing something here, or is what I'm asking for too much? Obvious solution would be to put debugging statements in my code for whatever CString operation I'm looking for, but I would prefer not to have to do this.
Update/Example:
CString blah = _T("blah");
Calling blah.IsEmpty() in my code works fine, but in the watch window of the debugger I get the error above (CXX0052). The contents of the variable blah can be seen the watch window.
I could reproduce your problem, and, indeed, the VS watch window shows Member function not found alongside with the error code CXX0052.
In the MSDN documentation I found that this problem arises due to a call of a inlined function, the CString::IsEmpty() member function is probably somehow inlined (this is what the Watch Window evaluator sees), to solve the problem, first open your project Configuration and disable inlining
Second, still in the project Configuration, choose Use MFC in a Static Library (somehow the Watch Window keep seeing the called function as an inlined one if you use it as shared library, maybe this is because in the Shared Library the code is inlined and the Watch Window evaluator don't use the Debug builds of such runtime libraries).
Third, clean and Rebuild your Solution.
After that, the problem should be fixed (remember to refresh the expression if you see the value grayed out in the watch panel) during debugging. Remember to switch back to your original Debug options or better, create a new Debug profile to keep this settings.
Related
I'm trying to debug a program in Visual Studio for which I have the symbols, but not the source code (it's a Unity game, the source in question is for the UnityPlayer.dll. I do have the source for the actual exe file).
The symbols load correctly, I can break into the debugger and can see call stacks with function names, as I expect to.
However, when I try to add a function breakpoint, it does not work: the breakpoint gets added, but it shows a little error icon in the Breakpoint window, and it's never hit.
If I double-click on a stack frame, I can get to the disassembly window, and the "Address" bar correctly shows the function name. However, if I try to enter any symbol name in the bar - including just copying the one it's already showing - I get an error message saying "identifier "whatever" is undefined". It's as if some part of Visual Studio is not aware of the loaded symbols.
One suspicious thing I noticed is that in the call stack window, all frames not in the actual exe file are shown with the "Unknown" language. I have no idea what is causing this.
Here's a picture to hopefully make this a little clearer:
What can I do to fix this, or at least work around the issue somehow? I've encountered this on VS 2017 and tried updating it to the latest version, and installing VS 2019, but nothing helped.
Notice in the names it's showing you, you get the parameter types too. Like, it's showing you FMOD_OS_Time_Sleep(unsigned int) and not just FMOD_OS_Time_Sleep. This is because the name is mangled, random looking characters are added on either side of the name to encode how many parameters it takes, and what types those parameters are.
One possibility is that it's expecting you to put in the mangled representation of the name. You can also try putting in the name exactly as it appears in the call stack, I would try both with UnityPlayer.dll! and without. Failing that, run strings on the dll to get the mangled representation of the function name and try that.
i coded a big project that runs when I open it in Debug or Release Mode, but when i open it without Debugging (ctrl + f5) it crashs. I searched a long time to find the heap error, but didnt find anything. The problem is i need the running .exe of the programm, so i wanted to ask if there is a possibility to link the windows debugger to the .exe so it always starts with it.
If it doesn't crash right away, maybe this helps:
You can run the executable.
Open your solution in visual studio. Make sure it's the same build.
Open the DEBUG menu and click attach to process.
A window will open, listing all processes that are running. Select the executable that's crashing
Click the DEBUG menu again and select Exceptions (ctrl-alt-E)
Make sure the checkbox "Thrown" is checked for Common Language Runtime Exceptions
Now crash your application.. It will halt at the line that causes it.
Also look for environment directives. like #IF DEBUG #END IF. or #IF RELEASE That kind of stuff. Tricked me a couple of times too..
Good luck. Hope this helps!
You can do various things. First make sure you have a "big out try block" in main. i.e. put the main logic in a try can catch exceptions and report these clearly. This probably isn't what's happening in your case.
You can attach a debugger - including Visual Studio, to a running process - see the "Attach to process" option under the debug menu. If it's built with debug symbols, which you can do, even for release code this may help. If it's optimised you may find it difficult though.
Finally, you could generate a crash dump and inspect that after it's failed. See docs on MiniDumpWriteDump. There are several examples on its usage. Or you can install an abort handler: See here. This mentions _set_abort_behavior which if invoked with _CALL_REPORTFAULT will generate a crash dump too.
I have an MFC application that uses an ancient (circa 1999) third-party ActiveX control.
Since upgrading the project from VS2008 to VS2010, I'm having problems...
In the OnSize handler of the parent dialog IsWindow always returns false for the handle returned by control.GetSafeHwnd(), even when GetSafeHwnd() returns a non-NULL value. The rest of the control's parent dialog is displayed fine, but it doesn't seem to respond to any input.
I've seen this article, but GetSafeHwnd() isn't returning NULL in this case (after the first time that it is called, which is before the control is instantiated).
The control does cause the trace message "Control wants to be windowless" to be output when it's loaded. However it also does this when compiled in VS2008, so this may be a red herring. Searching for this message points me to creating a class derived from COleControlSite, and denying the control windowless-ness, but it seems there are no good example of this available, and as I say, it's not clear that this is really the cause of the problem.
I've also found this issue mentioned on MSDN's VS2010 porting page:
"An ActiveX control compiled by using Visual C++ 6.0, when embedded in
a dialog box in a project developed by using Visual C++ 2010, may
cause your program to assert at run time. In this situation, open the
ATL or MFC project associated with the ActiveX control in Visual C++
2010, and recompile it.. The assert will be in the file occcont.cpp,
on this line in source: ASSERT(IsWindow(pTemp->m_hWnd))."
I assume that there's something about VS6-compiled ActiveX controls that causes the window handles to be treated as invalid by the current Win32 implementation of IsWindow. The suggested solution is of course unhelpful as it's a third-party control, and we can't recompile it.
Has anyone managed to get around this?
I've already found solutions for VS2010 projects not running on Windows 2000, and errors linking to ODBC, but don't seem to be able to find anything on this one.
Thanks,
Chris
I didn't find a solution to this in the end - upgraded the controls to a VS2010-compatible version.
For what it's worth: if you don't care whether the control will appear transparent or not, you may force the control to have a window anyway - even though it can operate without a window.
You see, the ActiveX control must first ask the container (the window which will host the control) if it's okay to be activated without a window. This is simply because not all containers support windowless activation.
If this interface (IOleInPlaceSiteWindowless) returns okay then it proceeds with this special windowless activation, if not a window will be created for the control as normal.
Disclaimer:
I don't know if this 'unnecessary' window will make the assertion failure go away. In other words: I don't know if the window handle is passed down 'deep' enough into the AX control.
More about the IOleInPlaceSiteWindowless interface:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682300(v=vs.85).aspx
Normally in Visual Studio, a watch cannot be evaluated unless the debugger is stopped at a breakpoint. Is there a trick or add-on to make Visual Studio evaluate a watch while the application is still running? For example, evaluate the watch every time execution passes a point in the code while it's still running and without changing the code to insert statements like Debug.WriteLine.
Not sure this is possible, but I thought I'd ask.
Yes, this is possible. Set a breakpoint at the location where you'd want to see the value. Right-click the breakpoint and choose "When Hit...". Tick "Print a message" and write an expression like { value }. The message is displayed in the Output window while your program runs.
I would do that using compiler directives.
#if DEBUG
Debug.WriteLine
#end if
No this is not possible to do. The evaluation feature in Visual Studio is a stack frame based mechanism. That is that every evaluation is done in the context of a given stack frame (as viewed through the stack window). When the program is running the set of stack frames is currently changing and hence it's not possible to do a stable evaluation.
Additionally there are other limitations in the CLR which prevent this from managed code. It's not possible for instance to execute a function unless the debugee process is in a very specific state.
My project has both client and server components in the same solution file. I usually have the debugger set to start them together when debugging, but it's often the case where I start the server up outside of the debugger so I can start and stop the client as needed when working on client-side only stuff. (this is much faster).
I'm trying to save myself the hassle of poking around in Solution Explorer to start individual projects and would rather just stick a button on the toolbar that calls a macro that starts the debugger for individual projects (while leaving "F5" type debugging alone to start up both processess).
I tried recording, but that didn't really result in anything useful.
So far all I've managed to do is to locate the project item in the solution explorer:
Dim projItem As UIHierarchyItem
projItem = DTE.ToolWindows.SolutionExplorer.GetItem("SolutionName\ProjectFolder\ProjectName").Select(vsUISelectionType.vsUISelectionTypeSelect)
(This is based loosely on how the macro recorder tried to do it. I'm not sure if navigating the UI object model is the correct approach, or if I should be looking at going through the Solution/Project object model instead).
Ok. This appears to work from most UI (all?) contexts provided the solution is loaded:
Sub DebugTheServer()
DTE.Windows.Item(Constants.vsWindowKindSolutionExplorer).Activate()
DTE.ActiveWindow.Object.GetItem("Solution\ServerFolder\ServerProject").Select(vsUISelectionType.vsUISelectionTypeSelect)
DTE.Windows.Item(Constants.vsWindowKindOutput).Activate()
DTE.ExecuteCommand("ClassViewContextMenus.ClassViewProject.Debug.Startnewinstance")
End Sub
From a C# add-in, the following worked for me:
Dte.Windows.Item(Constants.vsWindowKindSolutionExplorer).Activate();
Dte.ToolWindows.SolutionExplorer.GetItem("SolutionName\\SolutionFolderName\\ProjectName").Select(vsUISelectionType.vsUISelectionTypeSelect);