I'm running carbide 2.7 with 9.3 SDK FP2. I have two projects, one is an animation dll TARGETTYPE ANI and another is an exe that will invoke it.
what is the way that i should debug this in the emulator? what do i need to change so both the exe and dll are deployed in the emulator and i get to debug them?
Well I don't have access right now to a working Carbide, but you will need surely the followings:
load both projects to your workspace
at the debugger configuration (something like Debug... or Debug settings, I don't remember), there is a "load symbols" options and then you have to select "from all projects in the workspace" or at least tick your two projects.
sometimes this does not work. You can try to load the symbols at runtime, there will be a "load symbols from" somewhere in the menu system, you have to select your dll binary here.
try to put a breakpoint at the entry point of your dll
if you debug on the device ensure that you copy the debug variant of your binaries into the sis
Debugging multiple binaries in carbide is a bit of matter of luck, sometime you succeed sometime you don't as this part of carbide has some bugs. However it is definitely possible, I did it already in the past :)
Related
So I'm getting into c++ and I recently built a logger class ie print any type to the screen and/or to a log file. I built it as a dll and the output files are
console.h
console.lib
console.dll
I then imported these files as additional includes to another project and it works, only in debug mode (in which it was built) I wish for it to work regardless of build config. How can I accomplish this. An example, I recently used the GLFW library and can build in both how was it compiled for this to work.
If I correctly understood you're trying to link same version of your lib/dll with both debug and release configs of your app.
In general case you need two versions of your lib/dll files, debug and release, and link with the one that matches your application configuration, so for debug config of you app link with debug config of your lib/dll, and release with release.
The most possible problem of using mixed configs (like debug dll with release exe) is allocating memory in one domain and releasing it in another.
EDIT:
To elaborate, the problem can be allocating memory in your DLL and releasing it in your EXE, or vise versa. This doesn't work, at least with VS C-Runtime. For more details, see: https://stackoverflow.com/a/45806858/453271
Basically, I have a Visual Studio project that builds a DLL (a VST audio plugin). Where this type of project scenario has been set up for me in the past, I would be able to build, run, and debug the plugin. Visual studio would automatically launch whichever program I was using to host the plugin. I am trying to achieve the same effect in my current project, but I don't know how to set that up. Currently when I build and run my DLL in Visual Studio, I get the error "Unable to start program". The DLL still builds, and I can still run it, but I can't debug it from Visual Studio, because I don't know what I need to do in my project settings to make this happen. How can I do this?
MORE INFO:
What I do know is that, in projects where this sucessfully works, there are some modifications made to the Visual Studio project settings under fields marked 'pre-build events' and 'post-build events', so presumably what I want to do is edit these in some way to tell Visual Studio the following: "Hey, before you try and run and debug this DLL, you have to launch another program (my program is called Max.exe), and then you have to wait until that program loads the DLL. Then you can debug! Don't be a stupid computer and try to debug it before it's even loaded in Max.exe..."
What I do not know : EVERYTHING ELSE. This is literally all I know about what I'm trying to do, hense the colourful attempt to talk to a computer in English.
Currently when I build and run my DLL in Visual Studio, I get the error "Unable to start program". This is unsurprising seeing as the project knows nothing about the environment I want to use to test the DLL, but the problem is that I don't have a clue what Visual Studio needs to know. I really don't know enough about programming to understand the implications of what I'm trying to do either. Yes, I did mention those fields marked pre-build and post-build because I remember them being important, but I don't know exactly what or how to write in those fields, and I also do not know if there will be more things I need to tell Visual Studio before this will work.
Q.E.D I'm not actually sure what pre and post build events are, or how they work. And I barely know the first thing about customizing VS project settings. All I know is how to write audio processing code. I felt the need for this disclaimer because typically my questions are met with angry programmers who think I don't do my own research; they fail to realize I am an audio engineer who skipped programming 101. Yes, how to debug a dll is a common question I'm sure, but answers to those questions tend to assume pre-requisite knowledge that I do not have.
You will want to edit the Command field in your project's Debugging properties. Right-click on your project in the solution explorer and click Properties (it's generally the last item). Open the Debugging page under Configuration Properties. The Command field indicates which executable to launch when debugging.
By default this contains $(TargetPath) which refers to the final binary your project compiles. This is useless for DLLs since DLLs are not executable. Change this to the path of whatever third party application you are writing a plugin for.
With this change, launching with debugging will actually launch the third party application and attach the debugger to it. Once the application loads your plugin, you will be able to debug it normally.
For Visual Studio,
In Solution Explorer, right click on project and select Properties.
In Properties, choose Configuration Properties -> Debugging.
For Command, enter the full path of the executable that will be loading your DLL. Fill in the Command Arguments and Working Directory accordingly.
In addition, you need to make sure that the executable actually loads the DLL you are building. A mistake that a lot make is to launch their executable, and not realize the executable is loading another version of the DLL they are trying to debug. This can happen due to Windows searching for the first DLL that it finds using the DLL searching logic (exe directory, path, etc.).
I'm a developer of Windows desktop software, and from time to time our app crashes. In rare cases I'd like to get a customer to run a debug version of the app to send me a stack trace so I know where it crashed. I followed the instructions in here:
Windows C++ stack trace from a running app
...but while it works on my development machine, it doesn't work on any client machine or those of my colleagues, who don't have Visual Studio installed. So I presume that there's some .dll or something they need before it'll work. They're using the same .exe I'm using, i.e. the one I compiled in VC++ in debug mode.
After some painstaking "message window" debugging, I learnt it's failing in SymGetSymFromAddr64() - this returns FALSE. But when I walk the stack, this always returns FALSE or it returns garbage that doesn't make sense (random unrelated method names), as if it's the PC values which are invalid, not the mapping process. To reiterate, it's a debug mode .exe that produces a perfect symbolic stack trace on my development machine.
I did some research and found some mentions of "dbghelp.dll" and "imagehlp.dll" but I just ended up confused. "dbghelp.dll" ships with all versions of Windows, but with reduced functionality. There's some other things I could install, but it's a little scary to be installing some Windows "WDK" or "debug kits" which might overwrite important system .dll's or do god-knows-what to your computer.
So what I need to know is: "what's the simplest set of instructions I can give to these helper customers e.g. the minimum set of .dll's and where to stick them so that we can get proper symbolic information out of the stack traces when our program crashes?"
The most likely reason for failing to find the symbols is that the .pdb file cannot be found. Even if you generate a .exe in debug mode, the symbols are not in the .exe, they are in the .pdb file. Through a lot of empirical testing, it seems that the process has the pathname of the .pdb hardcoded in it, so if your clients don't have that file at that location, they won't necessarily find it. However, you can supply a "search path" to the SymInitialize() function - a folder or set of folders to use to search for the .pdb file.
In my configuration, I had an exe called "Edval.exe" and a .pdb called "DebugEdval.pdb". The process searches for "DebugEdval.pdb" in the search folders. This corresponds to what you've configured in "Properties > Linker > Debugging > Generate Program Database File".
When launching my app, I'm getting the below error dialog. I understand this indicates a problem loading the runtime library. The problem is, I'm not seeing any way to get more specific info. Which library? What was the exact problem it had when loading? etc.. System event viewer doesn't have any entries for it. Are there any tricks to finding out exactly which library it was trying to load when it hit the error and what the specific problem was?
Microsoft Visual C++ Runtime Library
Runtime Error!
Program: exe path
R6034
An application has made an attempt to load the C runtime library incorrectly.
Please contact the application's support team for more information.*
My current approach for dealing with runtime lib dependencies is to scan the install directory, extracting out the embedded manifests for the .dll and .exe files and then generating .config and .2.config files to re-direct to the minor versions of the runtime lib I'm shipping with. In the past this has always gotten things working. Not so in this case.
This might be complicated somewhat by the fact that the calling code is native C++ but some of the DLLs use .NET. I'm calling a C++ API, but under the hood it ends up utilizing some DLLs which themselves use .NET.
Use SysInternals Process Monitor to monitor file system access. Filter on process name and operation (CreateFile) to see what DLLs the process can't locate.
It could indicate a wrong version of msvcr*.dll.
You could try Dependency Walker (http://www.dependencywalker.com/) to find out where it's being linked.
Make sure you have a debug version of the code you're trying to attach to. On the Debug menu, select Attach to Process. Use processID -
Also check this -http://support.microsoft.com/kb/235434
Resolution 1
You should be able to attach to the process using Task Manager:
Enable just-in-time debugging (JIT):
In Visual C++, on the Tools menu, click Options.
On the Debug tab, make sure that Just-in-time debugging is selected.
Run Task Manager and select the process to attach to. Right-click and select Debug.
Resolution 2
Run Task Manager and get the process ID for the process you want to debug.
At a command prompt enter the following:msdev -p
This will start Visual C++ and will attach to the process specified.
I am an experienced Visual Studio developer who has recently taken on an OSX 10.6 project (a C++ server project with no UI).
I have been successfully debugging the application using the XCode debugger (setting breakpoints, etc.) for months, including debugging the source code for various static libraries that are linked into the final executable program.
However, tonight I was required to debug (with breakpoints) a DYLIB that is also built from our source code, but that is linked dynamically at runtime with the application (the name of the DYLIB is read from an .ini file by the main application).
Unfortunately, the usual method I use of debugging the application (right-clicking the custom executable and selecting "Debug with Breakpoints"), though it does successfully run the debugger and allow me to debug the application (along with its statically linked libraries), exhibits the following undesired behavior when I attempt to hit a breakpoint in the source code for the DYLIB:
-> The XCode debugger reports that the breakpoint was hit in the sense that I see the function and line number in the status bar at the bottom of the XCode windows (along with an indication that this is a gdb message), and the application halts execution. However, there is no stack trace, no variables, nothing - just a completely empty debugger window. The buttons to to "step over", "step into", etc, are disabled. No editor window appears in the debugger (and hence no visual indication that the debugger has stopped on the line indicated). Opening the file by hand does not reveal the debugger hitting the line.
Unfortunately, this is useless for me as far as my attempts to debug the DYLIB.
I have hunted far and wide tonight researching and attempting to find a way for the XCode debugger to successfully hit breakpoints in a meaningful way in the source code for this dynamically linked DYLIB. I have of course done a number of clean/rebuilds. I have made certain that "load symbols lazily" is unchecked and then cleaned/rebuilt. I have restarted, and I have also deleted the "build" directory and rebuilt. I also deleted the user-specific files in the .xcodeproj package. (Note also that I am of course building and running all code, including the DYLIB code, in Development mode with all optimizations off, and generating debug symbols for all.) However, my attempts have been unsuccessful. Nor can I find so much as a single mention of this problem on internet forums.
Any help in instructing me how to use XCode to successfully debug a DYLIB that is linked to my application would be appreciated.
Thanks,
Dan.
Update -
This problem is resolved. It was my lack of experience with OSX that caused me to fail to see this. Despite the fact that my DYLIB project was part of the same XCode project as the executable that calls it, and despite the fact that the DYLIB was built in the same directory as the executable, at runtime the debugged application was not accessing the DYLIB from this location. Instead, it was accessing it from a (different) install location. I have not as of this moment tracked down where the install location is "cooked" into the application, but by copying the final executable/DYLIB into the expected install location and creating a new custom executable that points to the executable in this location, debugging of both the DYLIB and the executable works.
Thanks,
Dan.