Is it possible to debug CImageList::Read(CArchive *)? - visual-studio

CImageList::Read(CArchive *) returns zero in my code.
Since Read only returns zero, without additional information about the error, I was wondering if I can somehow debug into the Read with F11?
I have disabled Just My Code Debugging but debugging continues as if I did nothing. I got winctrl2.cpp not found from Visual Studio. It offered me to click on Browse, which I did, and have pointed it to the file.
Now it works, I can enter the Read method, but in it, it asks for the file commctrl.inl, offering me the popup in which I must enter the file path.
I am using Visual Studio 2019.
If you know alternative solution on how to get helpful info about the error, I will consider accepting it as an answer as well.

Related

Visual studio form editor error

I have an error in my form editor preventing me from modifying the form.
I know in which control this occurs but no way to find what exactly causes the problem.
I tried setting breakpoints in the InitializeComponents() of the form I try to open but it doesn't stop (I am in debug mode...). I also tried to attach using a second instant of Visual Studio as demonstrated here, but even when setting all debug exception options to "throw", the attached process doesn't stop and indicate anything about call stack nor other useful information...
All I know is that there is a disposed object I'm trying to access, but absolutely no information as to where in code, etc..
What could I possibly do to debug the situation - knowing which control is the cause but absolutely no idea as to which of the 300 lines of code causes the issue...

Visual Studio 2010 - Memory Window - Edit Value

I tried looking on MSDN, Google and Stack Overflow and I couldn't find an answer to what I'm looking for.
Is there a way to edit, through the Memory Window, the code at a given address? I use the Disassembly Window to get the address of the instruction I would like to overwrite, find it in the Memory Window but "Edit Value" is grayed out. Any reason why? Is it because my code gets cached and VS prevents me to edit it? Is there a way to change that through project settings?
Thank you
The application is consisted of data parts and executable parts of code. Windows forbids the changes to executable parts by default, but this can be changed from the code with VirtualProtect function (also pay attention to remarks and FlushInstructionCache).
Maybe your ultimate goal is not to change some code from debugger, but something else that can be achieved differently. What do you really want?

How can avoid the window "No source available" while stepping into debug mode on VS2010 SL5

How to avoid the window "No source available" while stepping into debug mode on VS2010 SL5
In Tools, Options, Debug, General Page. Check if you have 'Enable .NET Framework source stepping' enabled, if it is enabled, disable.
I tried all the suggested fixes; Nothing worked for me.
I finally figured out the solution after several hours of trial & error iterations.
It turns out that the 'No Source Available' error is due to a stack-overflow within the VS debugger env.
The C/C++ code function that was supposed to be stepped-into (by VS debugger), was using a variable that was initialized to a stack array of a few MB in size. When I replaced this with a heap allocation, VS was successfully able to step into the code.
This worked for me.
Please note that in my case, the actual code (with the stack allocation) ran without a stack-overflow error within the debugger (if I skip the No source available error). It was just that VS's debugger's was not able to step-into a particular function sitting inside another C/CPP file, because of the internal stack overflow.
Hope this helps.
You can hit Shift+F11 to step out and it will complete whatever unavailable function it is in and stop at the next line (it may be unavailable as well, but continue to use Step Out until you get to code you want to examine.)
Regarding VS2019, a description for the issue is provided at MSDocs.
For the requisite vcruntime and ucrt source files, the problem can occur after importing from a previous VS version which has since been uninstalled.
To prevent VS from using the old directories, find the solution property pages and navigate to the Debug Source Files Dialog Box.
Click the tick button to check the entries where any invalid ones can be removed.
The vcruntime and ucrt source should always exist in the directories, and the path at the top of the Browse to find source code dialog should always show the correct path.
In my case, because of a venerable drive bug, it is given to prompt for the "D" drive instead of the "C" drive. Further, the provided path cannot be pasted over to refresh the view, so, if none the wiser, one has to use the dialog to navigate all the way up to the required location from the desktop or equivalent.
Here there is an extension for this issue:
http://erwinmayer.com/labs/visual-studio-2010-extension-disable-no-source-available-tab/
But in my own experience before finding this article (I was in page but I was trying to fix it myself without reading article) I have fixed this problem just by accepting a confirmation message saying something like "Selected source file is different from compiled assembly. Are you sure you want to use this file for debug?". But I can't remember exactly what I did to get this message. I think there was a linklabel which I clicked on "No source available" window and then confirmation message appeared and after confirm the problem ran away.

MS Access 2003 does not enter into debug mode and ignores breakpoints

I developed a small VBA procedure in MS Access 2003 module (just one public Sub)
The database is locked for me only, nobody else has access to the file.
My code works but there is a small bug I want to find and fix
I need to debug my VBA code. I put breakpoint at the first line of the procedure.
However, when I run this code, it never stops at the breakpoint and never enters to debug mode. Seems like VBA debugger is not working or disabled. I was not able to find any option how it is possible to disable/enable VBA debugger, I supposed it should be always enabled. Now I can debug this code only with the help of putting a lot of message boxes, but it takes a lot of time...
Please see:
ACC2002: Breakpoints Are Ignored in Visual Basic for Applications Code
Enable the Use Special Access Keys startup option.
To do so, follow these steps:
Open the database in which the breakpoint has been set.
On the Tools Menu, click Startup.
In the Startup dialog box, click to select the Use Special Access Keys
check box.
Click OK to close the Startup dialog box.
Close and then reopen the database.
Run the code that contains the breakpoint. Note that execution of the
code pauses at the breakpoint, as you
would expect.
Office 2010 Steps to resolve:
File
Options
Current Database
Make sure "Use Access Special" is checked.
Close and reopen Database.

Visual Studio cannot find debuggerutils.h

I've installed Visual Studio 15.9.0, Preview 3 and created a project using the new platform support for C++/winrt. The project runs fine until I set a breakpoint. When the break is hit VS tells me "You need to find debuggerutils.h to view the source for the current call stack frame" It tells me this file was originally at onecore\com\combase\inc\debuggerutils.h, though it doesn't tell me the path to onecore. Search can't find such a file. Does anyone know how to find that file or install it? I had just assumed that VS would automatically include debugging capability.
[Update] Appears it is not the setting of a breakpoint but a bug causing a break before that. But I'm still mystified by the error message.
Someone asked this question on github's WinObjC issues:
https://github.com/microsoft/WinObjC/issues/2931
From the discussion:
edvv commented on Nov 22, 2019
Ah, now I remember what this means: "This is a false message. What really happened is that your app silently terminated (maybe by a console abort(), i.e.: crashed ) and when the app failed to launch (aborted) the front end gave that message. You need to look at the Windows Console window in VS while in debug mode."

Resources