I've searched on this issue, and found many flavors and ideas but no real solutions. So, donning my asbestos suit and hoping for the best, I'm going to dare ask it again.
I have managed C# code that calls managed C++ code, which in turn calls unmanaged C++ code. The unmanaged C++ code is throwing an exception, and I'd like to be able to debug through it. However, when I try to (explicitly, via the Call Stack) load the symbols, I get the dreaded "The symbol file MyFile.pdb does not match the module" error.
I'm guessing that this is a generic error code being returned, as the files are from the same build. Using the chkmatch tool would seem to confirm that the files do in fact match.
Any help much appreciated...
wTs
Might be worthwhile checking the path of the loaded dll - are you using the one you thought you where?
If you are using incremental builds, you might also need idb files
I had an issue where MSVC just didn't want to see any debug symbols at the time, didn't work out why, but instead worked around the issue using CrashFinder or windbg instead. Perhaps a reboot will get it working again.
You might like to use symstore during your build to ensure all the pdbs are captured more reliably, that way you can debug across multiple builds of a file too.
Related
I've got a problem for which I would very much like a solution please:
All I'm trying to do is use wxWidgets in Visual Studio 2012 (in C++), and make it accessible to my code project. That shouldn't be so hard, should it? But as usual, even though there are programming tutorials for it, wxWidgets is evidently one of those things that has no proper documentation just to simply get it running, or if it does then I sure can't find it.
I downloaded the installer for Windows and installed it. When it finished, it gave me a message that said:
wxWidgets was installed successfully!
Please note: before using wxWidgets in your application,
you must build the library using the same compiler you
use for building your program.
Please see docs/msw/install.md file in the installation
directory for the detailed instructions about how to build
wxWidgets and use it from your application.
It should be noted that I think I remember something on the website or somewhere saying that I can just include a header file into my project and forego the DLL altogether (which is what I'd prefer to do, if possible), though I may possibly be misremembering that or confusing it with something else.
Anyway, when I opened the docs/msw/install.md file, I found (amongst other things) these instructions:
--- From the IDE
Ready to use project files are provided for VC++ versions 8, 9,
10, 11, 12, 14, 15, 16 and 17 (also known as MSVS 2005, 2008, 2010, 2012,
2013, 2015, 2017, 2019 and 2022 respectively).
Simply open wx_vcN.sln (for N=8, 9, 10, 11, 12, 14, 15, 16 or 17) file,
select the appropriate configuration (Debug or Release, static or DLL)
and build the solution. Notice that when building a DLL configuration,
you may need to perform the build several times because the projects
are not always built in the correct order, and this may result in link
errors. Simply do the build again, up to 3 times, to fix this.
Of course, it doesn't even say WHERE the "wx_vcN.sln" files are, but I ran a file search and found them in C:\wxWidgets-3.1.6\build\msw and I opened the one called wx_vc11.sln, because that seems to be the one that corresponds to VS2012, right?
Anyway, it took a LONG time to load, because it had to keep scanning through thousands of files and so forth, but when it was finally finished, I did the "Rebuild All" command thrice in a row, like it says to do (which also took a while).
But I'm not sure where it even put the actual DLL file. It says that it's in C:\wxWidgets-3.1.6\build\msw....\lib\vc_lib\wxmsw31ud_xrc.lib, but where the hell is "...."? It doesn't even bother to specify the entire path! What kind of nonsense is that?! I just want the file so that I can put it into my project! Or better yet, just a .h file that takes care of everything would be great. Supposedly there's one to include called "wx/wx.h", which then includes everything else, I think, but I don't know if that one indirectly also requires a DLL.
I always have problems with DLLs, anyway, though I'll use one if I absolutely have to. You'd think it would be the easiest thing to import a DLL into a project, but for some reason, I've never been able to find any sort of tutorial that explains a specific, step-by-step way to do it which is guaranteed to work, so on the rare occasion that I actually need to use a DLL (99% of the time I can just rely on my own code and the .h files included with Visual Studio), I always end up muddling through it until it FINALLY works by sheer accident (if I'm lucky). Mostly, it just reports errors for one reason or another, that it's not properly included or compatible, or that the header files that I'm using which reference it keep showing the same errors, as though I hadn't even imported the DLL file at all! I've been programming for about 30 years, and I work on things like AI and compression and cryptographic algorithms. I don't say this to brag, but to point out that if someone as experienced as me has trouble getting a DLL to attach properly to a roject, then there's something severely wrong with the whole process, or the documentation for it! I HATE using DLLS, because it's always a HUGE chore, but I'll do it if there's absolutely no other way (though I'd appreciate step-by-step instructions, if you don't mind).
But enough about that. In any case, I have an example project in which wxWidgets is being used in conjunction with Vulkan, and though it has compilation errors (because Vulkan didn't properly install on my machine (when I try to run the sample programs it says they're missing DLLs - big surprise) and as it turns out, I don't think it's compatible with my video card, anyway (which might possibly be why it didn't install properly), so I think I'll have to resort to OpenGL instead - PLEASE tell me that's compatible with wxWidgets!), but even in that example project, it has errors where it's trying to include and use wxWidgets stuff (like "wx/wx.h"), even though that's supposed to be a complete and already working project! I can't find any DLL files or the header files in question anywhere in the project directories!
So anyway, there's got to be an easier way to get this all set up, just to the point that I can make a simple test program using wxWidgets, and compile it. I'd REALLY like to be able to get at least that much working sometime tomorrow morning, so I'd greatly appreciate any help you can give me! Thank you.
#ThisIsMe,
First of all you need to educate yourself on properly using C++.
When you acquire the C++ code it contains of 2 portion - header file and source code.
Header file is what you call a declaration you declare you classes there - class name, member variable and method.
In the source files You define what you declared and you put an actual code there.
Now with that in mind:
wxWidgets contains both header and source files. When you downloaded the installer and did the installation it just copied the "text file" (headers and sources) into the folder of you choice.
Now as you can imagine text files are not executable - you need to compile them into the binary files And that is exactly what you did. (I don't know why you did it 3 times though - I guess you got an errors after building 1st and 2nd time).
Now, you said you have a project that (either uses wxWidgets or you want to incorporate wxWidgets into - which one is it, BTW?). The answer to this question will help direct you to a proper solution.
Now, you said that you tried the Vulkan and it fails to run the demo. How did it fails? Did it produce an error? What was it? Did it even run?
Now wxWidgets does support OpenGL as can be seen by looking at the documentation and checking the different samples that comes with the library, but I'm just curious if what you are seeing from Vulkan is really an incompatibility with the Video Card.
So, we need you to answer the questions I put and so we can help you further. Just keep in mind - C++ is not for the beginner programmers and if you are struggling with understanding the difference between compilation, installation , headers and sources - it will be very hard for you.
Maybe you should start with something simpler - like wxPython and forget about C++ for now.
I'm having a weird problem with Visual Studio. Whenever I change my code and build, even though I get the notification that the built was successful (and if any, it also shows errors in code and doesn't build) the executable is actually the previous build. This is getting really annoying and frustrating.
If I put a breakpoint on the new lines, the breakpoint gets disabled and it says
The breakpoint will not currently be hit. No executable code is
associated with this line. Possible causes include: preprocessor
directive or compiler/linker optimization
If I put a breakpoint on old lines of code, it stops processing but shows me this message
The source is different from when the module was built. Would you like
the debugger to use it anyway?
I never had this problem before and the source code in on my laptop's hard drive. It saves right away. The only way to get around this to Clean the entire solution manually every time, instead of basically pressing F5.
Thanks everyone for their suggestions. My mistake was that I defined the classes inside .cpp files, this somehow caused the linker to do weird (caching probably) stuff and link the old objects. I renamed the file to .h and everything's working as expected.
Perhaps your code is not built, or is built in a way you don't expect.
You might check by inserting a #error foobar preprocessor directive somewhere. If no error shows when building, you know you are in trouble!
But I never used Visual Studio (I'm only using Linux) so I cannot help more.
It might be that you have set main project some other project and building that.
make your project that you want to work on as "Main Project " by set main project available in menu bar.
I think you are using source files from another project (ex: if you are using a dll say, my.dll (which was built using some source files say, mycpp.cpp ); in your current project).
When you debugged into the file (mycpp.cpp), maybe you modified it.
Hence you need to rebuild the dll (my.dll) first in the project in which you created my.dll .
Or
Maybe you have opened a instance of mycpp.cpp in a window & debugging in another window.
you should rebuild the dll.
If you are not using files from another project, then I cant guess the cause...but still I would recommend using rebuild rather than clean & build.
please clarify your Question a bit.
#David expecting a reply from you...
I was looking for an answer to this issue since I was also stuck with it. A colleague of mine just gave me a solution that works. Yes, it seems really stupid, but it did the trick for me.
Our solution has many projects. He told me to select the project that I wish to break into and set it as the startup project (right-click on the project name and pick "Set as startup project"). I was desperate, so I tried. To my amazement, it works.
Since I have this window opened, I thought I'd share it in case someone else is stuck with the problem.
I faced the same problem. But reason was not as yours.
Then I just restarted the visual studio and it ran as expected.
I guess everyone has run into missing dll's issues from time to time. What I am trying to get is the 'recommended' method to find and install the dll's. Finding out which dll's are missing is easy enough using depends.exe.
Don't use depends.exe anymore, it hasn't kept up with developments in the Windows core and deployment strategies like the side-by-side cache. Trying to fix the warnings it gives will actually mess up your machine pretty badly. Only use it for hints if a program actually fails to start.
99% of the missing dll errors that I tend to come across are missing C++ runtime libraries (eg =MSVC*.dll=) or the .Net framework, where the developer has built with dynamic linking to the C++ runtimes but hasn't created an installer with the required merge modules, or they have built a debug version which links against the debug runtime libraries which you are not permitted to redistribute.
In the vast majority of these cases, simply installing the correct Visual Studio 2005/2008 C++ runtimes (eg see here) or .Net framework will fix the problem.
That depends greatly on which DLLs are missing and why they are missing, I don't know that there is a one-size-fits-all answer.
My advice would be to use depends to find which DLLs are missing, try to find out where those DLLs were supposed to be installed (and what application was supposed to install them), and then try to reinstall that application or find out what happened to screw up the dlls.
Another thing to check is for 32bit/64bit mismatches, that can make it seem like DLLs are missing sometimes, especially on 64bit platforms.
Or if you are using .NET, you can have trouble with assembly versions and the GAC sometimes.
You can also check the PATH environment variable, I would advise against blindly adding to your PATH to get it to find DLLs you want, that can cause all sorts of other weird problems.
Sometimes you have to hack around with the PATH or copy files to get things to work, but it is usually better if you can figure out what went wrong in the first place and fix it.
Get the DLL from its publisher's website, if possible, and then follow the publisher instructions to install. Don't forget to respect licensing rules!
I am trying to use a library (.dll) in my project. Everything seems to
be set up fine. It all works in release mode.
When I go debug on it, I get this darn error on startup:
ldr: ... application couldn't be initialized error (or similar, I translated it)
I learned that this has to do with manifest files.
I fumbled around a bit, in the project settings, but nothing really worked / I couldn't get my head around it.
The error persists.
Does anyone know a quick solution to this?
I don't care if it is dirty.
I think I liked dll-Hell better than manifest-Hell!!
The solution:
The wrong version of the .dlls got loaded. I didn't know that they were still
lying around on the system. Depedency Walker is a great tool and set me on the right track. So I will accept this answer.
Thanks a lot!
I always use Dependency Walker for debugging this sort of thing. It will tell you which dependencies your dll is missing.
Are you trying to run Debug-mode executables on a PC without Visual Studio installed? If so, you'll need to copy the Debug CRT DLLs onto it. See here: http://msdn.microsoft.com/en-us/library/aa985618(VS.80).aspx
Probably has something to do with dependent DLLs that are not available in debug mode (but are there in release mode). Make sure the debug DLLs you need are available (e.g. in the path).
My automated script for starting and stopping VMWare Server virtual machines has stopped working. vmware-cmd has started raising the error:
The ordinal 3288 could not be located in the dynamic link library LIBEAY32.dll.
I am not aware of any specific change or update when this started happening.
I have found a bunch of other people reporting this problem (or very similar) but no solution.
Do you know what caused this error, and/or how to fix this?
I would have said that something must have updated either the LIBEAY32.dll or another dll that depends on it. You may find some helpful information using the depends tool. If you use this to open up the perl.exe then it should highlight the dependency path that produces the problem. You can compare this with other machines on which perl runs.
The ordinal is effectively a function that is expected by perl or a dll, but is not present in the verision of LIBEAY32.dll that you have. The depends tool makes this quite clear.
Have discovered that this only occurs when the script is run on a different drive to the one where the EXE is located. As a work around for this I have simply moved the scripts execution.
Apparently the DLL relates to SSL, which isn't relevant to what I'm doing, so this is a suitable workaround. I'm guessing that the problem is caused by changes in the EXE for how it determines relative paths (unlikley as nothing (AFAICT) has changed). Or the %PATH% environmental variable has changed (more likely).
Hope this helps someone in the future.
Please check your path settings and see if you have included "C:\Program Files\VMware\VMware Workstation" for VMWare management purpose. Once you delete it, you won't see the error no more.