I used to work with VS 2008 but I am missing the following feature in VS 2010 when debugging MFC C++ app:
whenever an assertion occurs, VS 2008 automatically opens the source file and focus the line with an assertion expression
in VS 2010 I have to mark the file name and line of assertion and then manually open the source file and scroll to the expression
Is there some option or registry setting how to enable such behaviour in VS2010 like it works in VS 2008 ?
The first setting that really matters in in the Project + Properties, General page, "Use of MFC". You'll have no trouble if you select the "Use MFC in a static library" setting. This causes the linker to generate the debugger .pdb file entries for MFC symbols, giving the debugger an easy time to find the MFC source code files on your machine.
This isn't always practical however, the "Use MFC in a shared library" setting is the normal one. Which will load the MFC dll from c:\windows\system32, put there when you installed VS. Getting a .pdb for this DLL requires enabling the Microsoft symbol server, Tools + Options, Debugging, Symbols. Press F1 to get config help for this setting page.
You can verify this worked out by using Debug + Windows + Modules while debugging and checking the Symbol File column for mfc100xx.dll. Right-clicking the module and Symbol Load Information provides additional info, showing which directories were searched to find the .pdb
A further complication is that the .pdb that the debugger will download was created on a build server in Redmond which had the source code files installed in f:\dd\vctools\vc7libs\ship\atlmfc. Obviously not the directory where you have them installed. The IDE will prompt you for the actual source code directory. This prompt is often highly confuzzling so clicking Cancel on the dialog is a common thing to do. You now however bought the farm, the IDE remembers that you cancelled this dialog and won't prompt you again. You reset that by deleting the hidden .suo file in the solution directory.
Related
We have a legacy Visual Studio 2003.NET C++ DLL project. Still works with VS2003 on Windows 10 but we're looking to migrate to VS2019.
In VS2003 when you debug (F5), the box Executable for Debugging Session pops up. In the Executable file name box you select Browse... and navigate to the .EXE which will consume your DLL. Great!
But how to do the same in VS2019? Whenever I debug, Visual Studio thinks I'm using the Local Windows Debugger and I get the error "[PATH][PROJECT].dll is not a valid Win32 application". The Debug > Attach to Process... option is not right either because my target executable is not running yet.
If I'm understanding the problem correctly, I think you want to select the Debugging section of your DLL project's property pages. There you can choose which debugger to use and you can even set the executable you want to launch.
I've a solution which is ported from VS (Visual Studio) 2010 to VS2017 from one machine to another. I could debug while I can't. I need to know what's the problem. When running, I see the breakpoint marks get changed to include a warning, but I can't find what can be wrong. It seems that everything is ok.
1) Try to rebuild the application. Make sure that it's in the "Debug" mode.
2) If it works fine in VS2010 but failed in VS2017, I wonder if Visual Studio gets confused the configuration of the correct code type, if so you may need manually selected the .NET version. If you are using Framework 3.5 in VS2010, but on Visual Studio 2017 you are using such as Framework 4.6, by default automatically determines the code types to debug (v4.6, v4.5, v4.0). In this case you need to click in "Select..." button on "Attach to process" window and select Managed (v3.5, v3.0, v2.0).
3) Try to clear/delete all breakpoints from the Debug menu, choose Delete All Breakpoints. The reason is that it refreshes your Visual Studio setting file of your project.
4) Potential Workaround: Uncheck "Require source files to match original versions ..." in Options, Debugging.
In my case, changing from "Release" Mode to the "Debug" mode works!
When you launch the process, if the breakpoint icon turns hollow with the warning symbol, then the debugger cannot figure out what part of the program corresponds to that line of the source code. This is typically because the build is out-of-date with the executable, DLL, or PDB file.
A common way to get into the this situation is to not notice that the build failed and then let the debugger try to run the old executable which doesn't correspond to the current sources. It can also happen if Visual Studio gets confused about some of the dependencies and doesn't rebuild everything that needs to be rebuilt (which can happen after significant changes to the solution and/or project file(s), e.g., after an upgrade).
In these cases, clean out the build directory and force Visual Studio to rebuild everything. This will usually get you back in sync.
When you set a breakpoint in DLL code, that breakpoint will appear in the hollow warning state until the DLL is loaded. If your program uses delay-loading or if it manually loads the DLL (e.g., via a LoadLibrary call), you will commonly see this. Once the DLL is loaded, any breakpoint icons in the DLL should return to the normal red-ball state. If it doesn't yet you think the DLL should have been loaded. Check the Output window in the debugger to see if it really was loaded and whether there were any warnings or errors about loading the corresponding symbols from that DLL.
A strange error:
error MSB8011: Failed to register output. Please try enabling Per-user
Redirection or register the component from a command prompt with
elevated permissions. C:\Program
Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets 744
I got this error when trying to use OpenSceneGraph (OSG) in an ActiveX control. A Google search showed all kinds of solutions which didn't really solve the problem or locate the exact cause of the error, so I'd like to put the solution in one place: Here.
I found the solution to it, and will be answering my own question soon, so that people can find their solution if they encounter the same problem.
This error happens when Visual Studio (2010) can't find the dependent dll files that are required by the program for creating the OCX. The OCX is created in the Debug directory of the project (for Debug builds), and specifying the "Working directory" (in project settings) as the folder where the dependent DLL's are, won't help Visual Studio in locating the DLL's.
Now the catch is (this is what makes it a headache to solve the problem) that sometimes, without Visual Studio being able to create the OCX, you won't be able to run Dependency Walker on the OCX. So you'll never figure out that the missing DLL's are the problem.
If you know which DLL's need to be placed in the Debug folder, just place them there, and the error will disappear.
If you don't know, and if your OCX didn't get created, then go to project settings > Linker > General > Register Output
and set the value to "No". This will create your OCX for you, but won't go through the process of registering it, which is when it needs the dependent DLL's.
Once you double-click the OCX and Dependency Walker shows you the missing DLL's with yellow circle icons, just place those DLL's in the same folder as the OCX, and your program will work fine. It's that simple.
The issue could be that your project tries to register a COM object, but there are not enough privileges to do that. On Windows 7 and 8 regsvr32 requires administrative permissions.
What you can do is the following. Create a shortcut on your desktop to C:\Windows\SysWOW64\cmd.exe (the 32-bit console). Right click, Properties -> Advanced -> check Run as administrator. Launch the shortcut, and make sure User Access Control pops up, and click Yes. Start building from this special console window.
I tried using run as "Administrator" VS 2015, it's able to solved the problem
MSB8011 seems to be a generic error raised whenever regsvr32 encounters a problem. In my case, regsvr32 exited with code 4 when Per-User Registration was set to "Yes", but the DLL I was building did not define a DllInstall entry point.
You can also do this via VS 2013 IDE by launching this IDE from program files shortcut, Select Visual Studio 2010/2013 and then right click and select run as administrator, after IDE launched, then open your solution file and build it, you will never get such errors because of regsrv32 DLL/COM registration
On the Property page go to
Configuration Properties->Build Events->Post-Build Event
you might be referring to it as a /Service. Modifying options as shown below could help.
Before modification:
After modification:
I fixed this in Visual Studio 2019 by going to "Properties -> Linker -> General -> Per-User Redirection" and setting it to True.
Using VB6, I have created an Outlook plugin, that has a property page. The property page is an OCX control.
When I compile the project to an OCX file, and then run OUTLOOK, things work fine: I am able to see my OCX as a tab in the Outlook options.
However, when I try to debug by running the OCX in VB6 I get an error. My debugging is started like this:
1) Debug options set to Wait for components to be created"
2) F5-RUN project in VB6.
3) Start Outlook.
4) Get the error: "Cannot display "MyOcx" page. This page will remain visible, but is not available. An OLE registration error occurred. The program is not correctly installed. Run Setup again for the program"
I suspect this is because, when debugging, the OCX is being created out-of-proc and Outlook doesn't like that.
Is there a good technique to use the VB6 debugger on the OCX in this scenario?
The VB6 debugger is sometimes flaky when debugging DLLs or OCXs.
You could try Windbg, a free standalone debugger from Microsoft. Compile your VB6 OCX into native code with no optimisation and "create symbolic debug info" (i.e. create PDB files), and you will be able to debug your OCX in-process in Outlook. Here's a 2006 blog post by a Microsoft guy about using Windbg with VB6, and 2004 blog post by another Microsoft guy with a brief introduction to Windbg.
You could also use the Visual Studio 2008 debugger with VB6 and PDB files, e.g. with Visual C++ Express Edition (which is free). EDIT see Kris's answer for more details.
EDIT: Both Windbg and Visual Studio expect the source code to be in exactly the same path on the debug machine as it was on the build machine when the OCX was built. The easiest way is to build and debug on the same machine. Otherwise you might need to fiddle with SUBST to create virtual drives - or I'm told the serious way is to use a Symbol Server.
(Les serious) you could do without those newfangled interactive debuggers, just log to a file, or with DebugMessage calls from your VB6.
The only way you are really going to be able to Debug this is In Process as MarkJ said. Using the free Visual Studio 2008 C++ Express Edition (or even better, Visual Studio 2008 Professional if you have it, and it is available for a 90 day trial) and a PDB.
To make sure you are creating the PDB, go into Visual Basic, check the P)roject / P)roperties and click on the Compile tag. Make sure "Create Symbolic Debug Info" is checked.
Next start up Outlook, and attach to that process from Visual Studio (T)ools / Attach To Process. Make sure your Ocx is shown in the modules window, and then load the PDB (right click on the Ocx in the modules window). You will probably have to add the source code in the Solution Properties (for more details on how to do that, read this post).
It's a bit of a pain in the butt the first time, but once you can do it, it becomes pretty easy, and is far easier than trying to determine what is going on from a log.
I don't have much idea on the OCX.
However, you can use a tool which was part of visual studio named something like "activex control test tool".
As far as I know (based on my understanding of documentation), OCX is created in-proc.
I have created a minidump using win32 api
[DllImport("DbgHelp.dll", SetLastError = true)]
private static extern bool MiniDumpWriteDump(
dmp file is successfully created.
i am trying to open this *.dmp file in another visual studio instance to locate the place of the crash,
in visual studio --> FILE--> open project the dmp file option is not available.
i had choose all files in file open menu, and opened the dmp file. but i can't debug,
any idea why my dump file option in visual studio is disabled.
i know i can use windbg, and other tools, it will be easy for me to use visual studio as it is available for me.
I'm not 100% sure. But, I think even if you get it open in VisualStudio, VS doesn't support half the commands that WinDbg does for analysing a dmp. So, I'd just stick to WinDbg. WinDbg is a free download... so that's available to you too. It's not the easiest to use, I always have to open the help to find the commands I want, but it does do a good job.
Download here for 32bit:
http://www.microsoft.com/whdc/devtools/debugging/installx86.Mspx
It sounds like you are opening the dump correctly.
Here is what is says in the Visual Studio Help files:
"To open a dump file
On the File menu, click Open, and then click Project.
In the Open Project dialog box, locate and select the dump file.
It will usually have a .dmp extension.
Click OK.
To find the binaries for debugging a crash dump, Visual Studio 2005 looks in the symbol search paths. To make sure Visual Studio 2005 finds the binaries, you can add a symbol search path in the Options dialog box or from the Modules window. For more information, see How to: Specify a Symbol Path."
You yourself say,
"...and opened the dmp file. but i can't debug"
So you are opening the dump file OK in Visual Studio, but what do you mean, "I can't debug?"
If you can't see your source code, that's because Visual Studio doesn't know where it is. Follow the instructions to set up the symbol search path.
If you can't step thru your code, that's because you can't do that with a minidump. The process that produced the minidump is gone, and it can't be executed further.
If you can't examine the call stack or contents of variables, that's because Visual Studio can't find the .pdb file with the debug info.