Ok guys, I've been using Ubuntu for a while, so I've been coding all my projects using NetBeans on ubuntu. Now, due to external causes I need to code on Visual Studio/Windows.
I know migrating projects from one OS to another may be problematic so I made a new c++ project on Visual and included all the .cpp files from my project.
I'm having the next issues when I run it, this is the output:
'proyecto01datosWIN.exe': Loaded 'C:\WINDOWS\SysWOW64\ntdll.dll', Cannot find or open the PDB file
'proyecto01datosWIN.exe': Loaded 'C:\WINDOWS\SysWOW64\kernel32.dll', Cannot find or open the PDB file
'proyecto01datosWIN.exe': Loaded 'C:\WINDOWS\SysWOW64\KernelBase.dll', Cannot find or open the PDB file
'proyecto01datosWIN.exe': Loaded 'C:\WINDOWS\SysWOW64\msvcp100d.dll', Symbols loaded.
'proyecto01datosWIN.exe': Loaded 'C:\WINDOWS\SysWOW64\msvcr100d.dll', Symbols loaded.
I know it may be caused by some library, these are the libraries I'm using in different files:
iostream,
fstream,
sstream,
vector,
cstdlib,
string,
algorithm,
The program reads a .txt and generates a list of objects.
I'll been trying to figure it out but haven't been able to fix it!
Thanks for your time!
This is normal (it also does it for my c++ apps), there's no pdb files for the kernell32 dll. This should not impact your application.
Related
Can somebody help with the following error please?
'WidgetKeyboard.exe': Loaded 'C:\Windows\SysWOW64\wsock32.dll', Cannot find or open the PDB file
'WidgetKeyboard.exe': Loaded 'C:\Windows\SysWOW64\ws2_32.dll', Cannot find or open the PDB file
'WidgetKeyboard.exe': Loaded 'C:\Windows\SysWOW64\msvcrt.dll', Cannot find or open the PDB file
'WidgetKeyboard.exe': Loaded 'C:\Windows\SysWOW64\rpcrt4.dll', Cannot find or open the PDB file
'WidgetKeyboard.exe': Loaded 'C:\Windows\SysWOW64\sspicli.dll', Cannot find or open the PDB file
'WidgetKeyboard.exe': Loaded 'C:\Windows\SysWOW64\cryptbase.dll', Cannot find or open the PDB file
'WidgetKeyboard.exe': Loaded 'C:\Windows\SysWOW64\sechost.dll', Cannot find or open the PDB file
'WidgetKeyboard.exe': Loaded 'C:\Windows\SysWOW64\nsi.dll', Cannot find or open the PDB file
'WidgetKeyboard.exe': Loaded 'C:\Suneel\Keyboard\WidgetKeyboard\Debug glsdll md\iconv.dll', Binary was not built with debug information.
'WidgetKeyboard.exe': Loaded 'C:\Suneel\Keyboard\WidgetKeyboard\Debug glsdll md\zlib1.dll', Binary was not built with debug information.
The program '[6452] WidgetKeyboard.exe: Native' has exited with code -1073741701 (0xc000007b).
You don't give us much to start from. Apparently you are using DllImport in .NET (I guessed that from the tag, correct me if I'm wrong).
0xc000007b means STATUS_INVALID_IMAGE_FORMAT, and you are probably trying to load a 32-bit image into a 64 process or vice versa.
Usually, Windows tries to prevent that from ever happening. File system virtualization ensures that DLL loads from C:\Windows\system32 are redirected to C:\Windows\syswow64, and Registry virtualization ensures that COM servers are matched with the bit-ness of the COM client.
There's probably something that you did that bypasses these counter-measures. Maybe you copied DLLs to the same folder as your EXE. Or the resolution of the DLL path goes wrong, e.g. because you rely on the system's PATH environment variable or you used SetDllDirectory().
First of all, check that the bit-ness of your application matches the bitness of the DLL you are importing. If that fails, use SysInternals' ProcMon, which shows you what file it is trying to load.
That is an NTSTATUS error code. Look it up here: https://msdn.microsoft.com/en-gb/library/cc704588.aspx
In your case 0xC000007B is STATUS_INVALID_IMAGE_FORMAT. Described like this:
{Bad Image} %hs is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support.
Typically that means that the loader, when resolving load-time dependencies, is attempting to load a 64 bit DLL into a 32 bit process, or vice versa. The diagnostics you show suggest that your process is a 32 bit process. So you should look for the 64 bit DLL that the loader is attempting to load. Use the Dependency Walker tool in Profile mode to debug this.
This may come down to my misunderstanding of PDB files and the build process, rather than any particular problem but I've struggled to find a good answer elsewhere.
We have recently been good little developers and started indexing and storing our pdb files on a central symbol server (all part of TFS). The problem is that our PDB files do not appear to include all the source information.
When trying to navigate to sources in Visual Studio, the pdb files of our assemblies are found, as shown by the output window:
PdbNavigator: Downloader: file://server/Symbols/my.assembly.pdb/1DB3F79EA3094EAAADFC6CDE6515FC871/my.assembly.pdb -> ok, 251 KB
PdbNavigator: No debugging information found on symbol servers for my.assembly, Version=1.0.1.1206, Culture=neutral, PublicKeyToken=4cd79aeab39b919b
But at the same time it says it found no sources. If I use some of the tools from the windows SDK I can see that the PDB file does not contain the information on about 30% of the source files in the project.
I think I read somewhere that PDB files only include the source for classes actually used within the project, but surely that creates a massive problem for any API type assemblies where multiple classes may have no function within the assembly, only when used from some other part of your project?
If anyone can shed light on this, please let me know.
Thanks.
A PDB (normally) doesn't store source code - it contains a list of "documents", which are the source code file names, and "method information", which maps source lines to offsets in the assembly or binary. A PDB matches when the signature and build date of the assembly matches the same in the PDB file. Chances are, the MyAssembly.pdb has the correct version, but the signature and/or build date don't match.
The signature is not exposed as far as I know, but you may find some code on the Internet that says how to read a PE signature and a PDB signature so you can do a comparison.
When I try to run my Visual C++ application, a box comes up saying "The application was unable to start correctly (0xc000007b)." The only output is
Loaded 'C:\Windows\SysWOW64\ntdll.dll', Cannot find or open the PDB file
Loaded 'C:\Windows\SysWOW64\kernel32.dll', Cannot find or open the PDB file
Loaded 'C:\Windows\SysWOW64\KernelBase.dll', Cannot find or open the PDB file
But all of those files exist...which makes me think that its not the cause of the application's error. With no other output, I don't know what could be wrong. If anyone knows what I could check for or how to fix it, I would be grateful.
Few blueprints:
Rebuild the application, including all dependent DLLs, and try again.
Ensure all dependent DLLs, services (like MSMQ) are available and running.
Check if one of your DLLs DllMain is returing failure, which causes the application to start. OS won't start, if any of DLL returns failure while initializing.
Ensure you have correct CRT/MFC versions for the Debug/Release DLL you are using, or have linked other DLLs/EXE with.
Use Dependency Walker to find out of any DLL is missing, not found, or of different platform.
A colleague of min told me he read once that re-building opencv should fix this. Which worked for me. Notice I'm using opencv1.1(x86) under a win7 64-bit cpu.
Best of luck.
Hasan.
I have a mindmp file from a target's application crash. Is it possible for me to rebuild the dll/pdb files for a version of software and have windbg load symbols correctly?
My problem is that our pdb files are only kept for major releases (unfortunately). This is a daily build, which I can rebuild myself, but I'm getting tripped up on errors.
With !sym noisy on:
"image header does not match memory image header."
DBGENG: C:\...\XXX.dll image header does not match memory image header.
DBGENG: XXX.dll - Partial symbol image load missing image info
DBGHELP: Module is not fully loaded into memory.
DBGHELP: Searching for symbols using debugger-provided data.
DBGHELP: C:\...\XXX.pdb - mismatched pdb
Note I've build the pdb with the dll, they are from the same RELEASE directory (should I be building debug?)
Theses are release builds (as release builds are installed on the target and crashing) should I be somehow using the debug build dlls to get more symbol information?
The ChkMatch utility is designed for this exact scenario.
As long as you have the original .EXE, you can recompile the sources (with the same compiler and compiler settings) and patch the new .PDB to match the old .EXE.
In this example, OriginalExecutable.exe is the executable that no longer has a .PDB file, and RebuiltPDB.pdb is one that has been produced by rebuilding the original source.
chkmatch -m OriginalExecutable.exe RebuiltPDB.pdb
Now, as long as the two files have their original names, The debugger should accept them as a matching pair.
In my experience probably not.
If you have the exact build directory and build with the exact same compiler settings then this might work. You definitely will not be able to load symbols from a debug build against a release crash dump.
You will need to turn on the 'load anything' options: .symopt+0x40 to get windbg to ignore the timestamp differences.
if you still have the exact source code the image was compiled from, then rebuild it producing a new pdb file and then instruct WinDbg to forcibly load this pdb when you open the crash dump - it worked once in my practice.
PDB files are tied to their EXE files by a GUID and an "age" (it's a sequence number). These are embedded in the EXE, and into the PDB. The GUID is regenerated on each complete build, and the "age" is changed on each incremental build.
The debugger uses these to ensure that it's looking at the correct PDB for the EXE file.
I didn't know about the "chkmatch" tool mentioned by SteveMan, but I suspect that it works by patching up the GUID/age so that they match.
This is too late to help Doug, but for the sake of anyone who comes across this question, another thread (Is it possible to load mismatched symbols in Visual Studio?) pointed out a way to get WinDbg to accept mismatched .PDB files
.symopt_0x40
I have heard using PDB files can help diagnose where a crash occurred.
My basic understanding is that you give Visual studio the source file, the pdb file and the crash information (from Dr Watson?)
Can someone please explain how it all works / what is involved?
(Thank you!)
PDB files map an assembly's MSIL to the original source lines. This means that if you put the PDB that was compiled with the assembly in the same directory as the assembly, your exception stack traces will have the names and lines of the positions in the original source files. Without the PDB file, you will only see the name of the class and method for each level of the stack trace.
PDB files are generated when you build your project. They contain information relating to the built binaries which Visual Studio can interpret.
When a program crashes and it generates a crash report, Visual Studio is able to take that report and link it back to the source code via the PDB file for the application. PDB files must be built from the same binary that generated the crash report!
There are some issues that we have encountered over time.
The machine that is debugging the crash report needs to have the source on the same path as the machine that built the binary.
Release builds often optimize to the extent where you cannot view the state of object member variables
If anyone knows how to defeat the former, I would be grateful for some input.
You should look into setting up a symbol server and indexing the PDB files to your source code control system. I just recently went through this process for our product and it works very well. You don't have to be concerned about making PDB files available with the binaries, nor how to get the appropriate source code when debugging dump files.
John Robbins' book: http://www.amazon.com/Debugging-Microsoft-NET-2-0-Applications/dp/0735622027/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1222366012&sr=8-1
Look here for some sample code for generating minidumps (which don't have to be restricted to post-crash analysis -- you can generate them at any point in your code without crashing): http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx