I have a program that uses different dlls and it crashed.
I am trying to work out the cause of the crash using WinDbg but I am having no luck so far.
I have the .dmp file but I have tried addig that as the symbol path, I have tried adding the dlls in th symbol path also and a few other things but it keeps telling me it could not find myprogram.dmp/symbols etc or just that the symbols could not be found.
What is the right method to get it working with the .dmp file?
Thanks I am new to this and finding online documentation only seems to help for programs that don`t have DLLs and other non built-in DLLs.
Example of some of the errors:
* ERROR: Symbol file could not be found. Defaulted to export symbols for mydll.dll
* ERROR: Module load completed but symbols could not be loaded for myprogram.dll
PDB not found : c:\users\me\desktop\myprogram.dmp\symbols\dll\ole32.pdb
I managed to load the default windows symbols adding the downloaded symbols to the symbols path. Must I add DLLs I am using in my project to the symbols folder or something?
PRIMARY_PROBLEM_CLASS: WRONG_SYMBOLS
C:\Users\me\Desktop\Assignments\4. DPI-600 Testing\DumpFileDebugging\symbols
First, set up a path for your private symbols. Let's call it X:\mysymbols. Copy all PDBs into that folder, just as a flat list. In WinDbg, set the symbol path to that folder
.sympath X:\mysymbols
Next, let WinDbg find the Microsoft stuff. Create a folder X:\microsymbols. Put nothing inside and do not use the same folder as X:\mysymbols. Add that folder to the symbol path:
.symfix+ X:\microsymbols
Now that everything is set up correctly, tell the debugger to refresh:
.reload
In rare cases only a
.reload /f; ld *
helps.
If you're still unlucky, try
!sym noisy
so that the debugger tells you what exactly is wrong with the symbols. Look up the error messages and try to fix them.
If it still goes wrong, you might simply not have the correct PDBs. PDBs are correlated to modules (DLLs and EXEs) by a kind of hash / timestamp. So either get the correct PDBs or try
.symopt+ 0x40
which forces the debugger to load whatever he gets without checking the hash. Be aware that callstacks etc. may be misleading if they are too far off.
Related
The top line of my code 'module Title' is giving me a dual warning "The search directory 'C:\z3-4.3.0-x64\bin\' could not be found". One for my .fs (f#) file and one for some FSC file. I believe FSC is or has something to do with the main project file.
Although I suppose I could try placing a z3 library folder in that specific location, I really don't want to. I have to localize this project for portability. I'm not sure if that file path string is hardcoded or if it was generated from asking my system where things like that are supposed to be installed.
When I search for things like "The search directory" + "could not be found" + visual + studio, I don't get any interesting results.
This path is not hardcoded in Z3 or in F#. It's possible that someone added it to the system settings, e.g., the PATH variable, but that wouldn't produce this warning. By the folder name, I would conjecture that somebody downloaded the Z3 distribution (.zip) and unzipped it in C:.
It can really only be something that's left over from previous projects, e.g., either in the project settings or in the global Visual Studio settings. It seems F# is searching for a module and while doing that, it finds that the directory doesn't exist, which is only a warning because finally all modules can be found elsewhere anyways.
Regarding 'FSC', that's the name of the F# compiler, quite possible that this name pops up in some error messages etc.
I am currently trying to add control to a Power Analyzer in an excel tool. The company provides USB drivers and the appropriate modules and DLLs. I added the DLLs to the System32 folder to ensure they were read in the path. After importing the modules and trying to run the program, I get the error "File Not Found". I then tried to hard code the location of the DLL and I received the same error.
I've looked around the internet and the only issue I could find was possibly a dependency missing from the DLL. An example of the line I'm trying to use is:
Declare Function TmSend Lib "tmctl.dll" (ByVal id As Long, ByVal msg As String) As Long
This line is apart of the module provided by the manufacturer. Is there something I'm missing to get this to work? I want to make sure before I contact the manufacturer.
EDIT:
It appears that the manufacturer uploaded a corrupt DLL causing the issue to arise. When checking the file with Dependency Walker, it failed to even read the DLL.
I see from your question that you've tried all the normal things (making sure the dll is on your path &c.)
You now need to examine the dll carefully. Download this: http://www.dependencywalker.com/
Then use it to open your dll. All the missing dependent dlls will be clearly displayed. Put those on your path too and you're done.
(To clear up some confusion: you will not need to register this dll or add a reference to it.)
I'm trying to build a solution that has three VB projects; one that I'm working on, and two others that have interdependencies (although one says "unavailable").
In trying to compile, I get regarding the ancillary project, "Unable to find source file 'J:\DSDPAGE_T.xsl' for file 'DSDPAGE_T.xsl', located in '[TARGETDIR]', the file may be absent or locked."
J? I searched the solution to see if "J:" is hardcoded anywhere, and it's not, so...?!?
The "missing" files are right there n the project! Why is it looking in J? If that is hardcoded somewhere, why doesn't 2-clicking the err msg take me to the spot? When I do, a "File System " tab appears with two panes. On the left:
File System on Target Machine
Application Folder
System Folder
User's Desktop
User's Programs Menu
...and on the right pane, a listing of the files in that project (the same ones I see in Solution Explorer), many of whom are the subject of err msgs that they cannot be found...?!?
Is this a "VB thing" (I've never worked with VB before) or...?!?
Maybe I can create a J drive and put those files the compiler is wearing blinders about in there just so it will compile - it's not that project I need to work on anyway, I just need to let the solution compile, so I can update the other project.
UPDATE
Looking at one of these files that is visible in the project, but for which the project exhibits acute myopia, its "SourcePath" property does say "J:\DSDPAGE_T.xsl" but that property is readonly/grayed out.
UPDATE 2
In response to user2701753:
I know what you're talking about; I'm used to having these in C# projects; but in this case, there are no References folders. There is only:
Solution 'HDP' (2 projects)
HDP [project#1]
ReportFormats [folder]
[a bunch of .xsl files]
[a bunch of .vb files]
HDPSetup [project#2] <-- the problem child
DetectedDependencies [folder]
[various files: .dll, .xsl, .exe, .chi, .chm, .mdb, .bmp, .ico]
The "Detected Dependencies" folder (which I thought was maybe the VB version of References) is apparently empty - 2-clicking it does nothing; it doesn't expand or open up.
UPDATE 3
Here is perhaps a good clue: When I look at the project files in Windows Explorer, many of the files that display in Visual Studio are not seen there! For example, C:\Project\ccr\Handheld\Development\Development\HDP\HDP\HDPSetup only has this:
Debug [folder] <- empty
Release [folder] <- empty
HDPSetup.vdproj
HDPSetup.vdproj.vspscc
ccr.bmp
ccr.ico
According to VS, I would expect to see those files that it complains about being on the (nonexistent) J: drive.
UPDATE 4
This is related to the issue above.
To recap the gist: I am trying to port/upgrade a VB.NET (.NET2/VS 2003) solution to .NET4/VS2010.
The solution is comprised of three projects; the Setup project was wreaking more mayhem and malevolence than a marauding crash of rhinoceropuses (it was thought to be on drive J, apparently), and I don't need to do anything to that project, so I removed it from the solution.
That removal reduced my error count from 35 to 14.
However, the remaining errs seem related to the "other" project. There are now two; I'll call them HDP and HHTConvert (because those are their names, and my current employer doesn't seem to be as paranoid about divulging any info that would identify the company or project as my previous one was).
Although the Project Dependencies allows me to set one as dependent on the other, no matter which way I set it, it fails:
0) Both depending on each other - disallowed, circular jerk tailchasing considered bad juju
1) HDP depending on HHTConvert: Type 'HHTConvert.HHTConverter' is not defined.
2) HHTConvert depending on HDP: ""
3) Neither depending on the other:""
So it doesn't matter what I do, the same err msg appears. The line the err points to is:
Public hhtConvertThread As HHTConvert.HHTConverter
What do I have to do to introduce the HHTConvert project to the HDP project? It would seem them being in the same solution - especially when one "depends" on the other - would be enough. HHTConverter is apparently not very dependable.
UPDATE 5
Correction/amendment to my original statement: "I'm trying to build a solution that has three VB projects"
Actually, I successfully removed one project, so it is two projects, and one is C# (the "main" one, HDP, is VB).
Could that (the C#/VB "mismatch) cause the two projects to look askance upon each other, akin to the renowned Star-bellied Sneeches and the "plain vanilla" Sneeches? (I consider the plain ones to correspond to VB).
UPDATE 6
So I've got it compiling now (see my answers), but I'm getting a subsequent (runtime) error, namley: "Unable to load DLL 'cdbmenu1.dll': The specified module could not be found."
And sure enough, one of the VB files does references a DLL with that rather bland name several times, with lines such as:
Declare Sub GetLastMenu1Error Lib "cdbmenu1.dll" (ByVal Msg As String, ByVal Length As Int32)
So, I searched the local (work) network and found some copies of that DLL. I copied the newest version (2.5 years old) to HDP's bin folder, and tried to run the app. Now I get, "An attempt was made to load a program with an incorrect format"
Is this the part of the story known as "DLL Purgatory" or a rendition of "DLL Perdition"
(geschweige denn "Extraordinary DLL Rendition")?
Look at the 'References' in the projects in the Solution Explorer, these have a 'Full Path' if that's wrong drop the reference and readd it.
In the visual studio setup project have you added "active content" from VB project? Open your VB project file in a notepad, check the different files included in your project file, your setup project will try to include all those files as a part of your MSI. So open the project file and you should see the J drive there.
All those files can be taken out from the project and then re added.
I solved it: I had to add the .DLL from the C# project to the VB project's References. Once I did so, all errors disappeared. Why that wasn't already there, I have no clue.
i tried to port the SimpleFTPsample from apple from this IOS project to my OSX project, but when I try to build I get the following error.
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_NetworkManager", referenced from:
objc-class-ref in Document-DAE96E3625ECED63.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I've searched online, and have been checking all the code I copied twice, all frameworks are added, and the headers included. could somebody please help me to find whats wrong, or even better explain what this means so i can solve it myself in the future? how can i find out what is wrong in the NetworkManager class? i dont get any errors before compiling.
thanks
---EDIT---
forgot to mention that i only need the PUT part of the code in the example, i am only examinating that part. all the rest hasnt been copied over. i copied the NetworkManager.h, NetworkManager.m and copied over the parts of the code that i need from the PUT file.
Usually, when the linker says “what? I've never heard of that class”, it means that the module that implements that class (SomeClass.m) didn't get compiled.
There are two ways that that happens:
Compilation failed
This one would cause an error asking for SomeClass.o (in your case, NetworkManager.o). That's not the error you got, but similar enough that I felt it was worth listing here.
The linker will want an object file, which is produced by a successful compilation. If compilation fails, the object file doesn't exist, so you'll get the “file not found: blah/blah/blah/SomeClass.o” error.
999‰ of compilation failures are because the module contains an error—a syntax error, an unrecognized name (e.g., spelling error/typo), or some other flaw that fails compilation.
Build errors causing other build errors is fairly common, so you should always tackle errors from the top of the list downward.
The solution to this one is to navigate to SomeClass.m and fix everything that's wrong with it, and then try the build again.
You didn't even try to compile it
This is the one you ran into.
Every target has a list of build phases, each describing something that needs to be done to build the target. Most targets have at least Compile Sources and Link Binary with Libraries phases. Every build phase has a list of input files.
The input files for a Compile Sources phase are the module files that Xcode will try to compile. Link Binary with Libraries will implicitly link in everything that the compiler produced—all of the object files—along with the libraries in its list, such as Cocoa.framework.
For each target, Xcode will only try to compile modules that are in that target's Compile Sources build phase.
It's quite possible to forget to add a module to a target but still try to use it in another module within the same target. Maybe you made the module a long time ago for another target, and now want to use that code in the target you're working on now, or maybe you simply forgot to check the box when you created the module or otherwise added it to the project.
Either way, you'll get that error message, telling you that the module whose contents you're trying to use isn't listed for compilation in the target you're trying to use it in.
There are two ways to fix it:
Select or navigate to the “missing” module and show the File Inspector (⌘⌥1), and check the box for the appropriate target under “Target Membership”.
Select the project object in the Project Navigator, select the target within the editor, switch to the Build Phases tab, and drag the “missing” module from the Project Navigator into the Compile Sources build phase.
The way to prevent it is to make sure the relevant targets are checked when you add the module to the project. This includes both creating new modules and adding modules you've obtained from other people (e.g., open source reusable classes).
I made some test and I was able to create and remove boost::interprocess::shared_memory_object in a C++/CLI executable without problems. In a C++/CLI dll plugin I'm only able to create the boost::interprocess::shared_memory_object but the removal fails. I verified that the file exists at the time of removal - it is present in boost::interprocess folder in a subfolder named "20110606204418.125000". The memory hasn't been mapped by any other process. Any ideas what might be the cause? At the beginning I thought it may have something to do with the project being a dll and targeting CLR but honestly I don't know.
EDIT: the removal code is called by a different thread than the creation code - is this disallowed?
During debugging I noticed that the file path that is to be removed inside boost::interprocess::shared_memory_object::remove is different from the file created by boost::interprocess::shared_memory_object constructor - the path to be removed points at the root of "boost_interprocess" folder while the actually created file is in the "boost_interprocess/20110606204418.125000" folder. So I reported a bug to boost. We will see what they do about it.