In C++, on this site: http://msdn.microsoft.com/en-au/visualc/bb985511.aspx
I downloaded the code sample and went to Debug and it came up with a messagebox with 2 textboxes in it and told me to specify the executable file to debug. So I did, and then I clicked browse, but there is NO executable because the stupid thing hasn't created one yet.
I'm using visual studio c++ 2008; what's up with that weird message?
This message generally comes up when you try to debug into a system DLL or 3rd party code. Set a breakpoint with F9 and hit F5 and see if stop in your code in debug. Also make sure you are building the debug version.
happy coding.
That project builds a DLL. If you're going to debug a DLL, you need to provide a .EXE that loads the DLL.
Related
I have a simple application which reads a few text files does some calculations and writes a few text files. Works perfect on my development machine (Server2008R2 VC++ 2010). I can't get it to run on a Win7 machine even thought I have installed/run the vs2010 redistribute x86.
The first error I got was missing mfc100ud.dll (yes, I'm using debug, if I try the release it just crashes, as debug tells you what's wrong). I put mfc100ud.dll in the application's directory, now fgets asserts as shown below. str is not null and the file did open successfully.
What have I missed?
My goal here is to just run the MFC app on the Win7 machine without have to install vs2010.
Another consideration, the only reason I am using MFC is for the COleTimeDate functionality. I've looked for alternatives but haven' found anything workable or as simple to use.
Thanks.
Assertion Error
This error occures if the file stream pointer (provided by fopen) is NULL.
Is it possible that you don't have any error checking after you used fopen?
Basically use "static linking" to the MFC and CRT. Than there is no Need to install and copy any runtime files.
Redistributable assemblies are only available for release builds. If you really want to distribute a debug build, you have two options:
link your app statically, so you don't need any shared DLL (such as mfc100ud.dll)
distribute together with your app (in your app folder) all the dependent DLLs. you can check the dependencies with depends.exe
I feel like this is a stupid question, but I can't seem to figure out the answer. I've currently got a C++ application that's loading & utilizing a DLL (I compiled both the application & the DLL with VS 2010). I'm positive it's using the DLL, because a) if I rename the DLL, I get a not found exception, and b) it's displaying output that only comes from (and I can change it to see the output change) inside the DLL.
My problem is that in Visual Studio's Modules window while debugging, the DLL does not appear to be loaded. Because of this, obviously its got no symbols and I can't set breakpoints... But this doesn't make any sense to me as it's clearly using the DLL.
I've seen several other similar questions, and the answer has generally been too look at whether the code is native, managed, or mixed, and set the "Attach to Process" field accordingly. I've tried all the options there, and made sure my Debugger Type is set to "Mixed" (though I've tried it with Native & Managed as well, just to verify none of these solve the issue).
Does anyone have any suggestions?
Thanks in advance!
This happened to me and I found the project->properties->Debug page and clicked the box to Enable native code debugging. I was doing a C# project accessing a C++ / native dll
budward
I have some ideas:
check output windows it the DLL symbols are missing.
Make sure dllname.pdb file exist beside the DLL
make sure visual studio solution has two projects (EXE,DLL) projects
switch to DEBUG mode instead of RELEASE mode.
run process explorer (download it from MS) and check the path of the DLL that is bonded to the EXE in runtime.
Finally the ultimate solution:
Open Process Explorer and search for your DLL name.
Find which EXE is using it.
Goto VS and attach your debugger to that EXE.
I hope any of those fix your issue
I am running a Qt C++ Project in Visual Studio 2008 and I got this error message:
"The program can't start because QtCored.dll is missing from your computer. Try installing the program to fix this problem".
Then I copy: QtCored4.dll from C:\Qt\4.8.0\bin to the exe program
I run it again, I got:
"The program can't start because QtGuid4.dll is missing from your computer. Try installing the program to fix this problem".
Then I copy: QtGuid4.dll from C:\Qt\4.8.0\bin to the exe program
Then I run it again, I got:
"the application was unable to start correctly (0xc015002). Click OK to close the program.
Then I check the Event Viewer, I see this:
Activation context generation failed for "D:\rest\rrpT.exe". Dependent
Assembly
Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762"
could not be found. Please use sxstrace.exe for detailed diagnosis.
First of all, it is very strange to me because I am building and debugging the application on VS2008 but it asks for the dll files form VS2005. Then I copied those files from VS2005:
msvcm80d.dll - msvcp80d.dll - msvcr80d.dll
to the program folder but it is still the same error :(
And I think there is also something interesting:
Activation context generation failed for "C:\Bin\QtSolutions_PropertyBrowser-2.5d.dll". Dependent Assembly Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762" could not be found. Please use sxstrace.exe for detailed diagnosis.
why is that PropertyBrowser is dependent on VS2005?
Any idea?
It sounds like your copy of Qt was compiled with VS2005, thus it probably has a dependency on the version 8 runtime DLLs. But your application is built with VS2008 and thus has a dependency on the version 9 runtime DLLs. In general, you can't get both versions of the runtime DLLs into one process. VC++ tends to break binary compatibility between major versions.
You need to recompile your own copies of the Qt DLLs with VS2008 or develop your application with VS2005.
In Visual Studio 6, I have written an ATL COM server EXE. I want to debug this and put a breakpoint at the start of the method I am calling. I start debug and then call the method from the other EXE but the breakpoint is never hit. This was working fine a couple of weeks ago. I could break into it no problem. I can't work out what has changed that this is no longer working. Can anyone help?
Your exe or pdb probably don't match the source. Try rebuilding the project, and make sure the executables you've just built are used by the server.
FWIW, you can also place a call to DebugBreak in your code. If the source and executables indeed don't match, the debugger will let you know when it breaks.
I have a native C Dll that calls 'LoadLibrary' to load another Dll that has the /clr flag turned on. I then use 'GetProcAddress' to get a function and call it on dynamically loaded dll. I would like to step into the dynamic library in the debugger, but the symbols never load. Any idea?
And I should have said I'm using Visual Studio 2008.
Update: Thanks to some tips below, I changed the project debugging to Mixed. It didn't work, but I think I know why. I am developing an addin to an existing application. The app I'm connecting to starts one exe then it starts another. So I have to use "Attach to process" to fire up the debugger. My guess is launching the debugger that way will default to "Auto". Is there a way to change the default behavior of VS to use "Mixed" debugging?
This is from VS2008, but if I remember correctly VS2005 was similar. In the native project's properties, under "Configuration Properties->Debugging" there is a "Debugger Type" which is set to "Auto" by default. You'll need to change it to "Mixed", because VS isn't smart enough to realize you need managed debugging
I've had mixed experiences with doing similar things like this in VisualStudio. You might consider using ProcMon to see where VisualStudio is looking for the PDB file. Alternatively, you might try using WinDbg. It seems to do better at loading symbols and if it doesn't, you can explicitly load them yourself. Using WinDbg involves riding a steep learning curve, but if you're burning time right now, isn't it worth it?
You can also run the exe on its own and from the source of the managed dll, attach to the process to debug it.
Modify the mixed-mode dll to throw a CLR exception where it enters the first code you're interested in debugging. This should give you an opportunity to launch the managed debugger.
In VS2005, there are per-project options to enable native and CLR debuggers separately. You might need to enable the CLR debugger for the native dll project from which you start the debugger.