I've set Windbg up as the debugger for my development system. And, sure enough If I induce a trap in some of my programs up pops the dialog; I click the debug button; and the source file is displayed with the faulting line highlighted. Mouse over and local vars windows work.
Today, I writing a fairly simple standalone C app, made a mistake and got a trap. But this time hitting debug no source; just the console window.
If I set a breakpoint on main and hit f5, sure enough the source code appears, but the mouse-over variables doesn't work nor the local variables window.
The program is compiled for debug /Zi /Od and the .pdb (& .ilk?) are right there along side the source and executable.
If I invoke the executable under windbg manually, same thing. No source until a run to a break point within it. Then no local var knowledge.
If it can find the appropriate information for one app; why not the other?
Cheers, Buk.
Windbg doesn't know the location of the PDBs, even if they are in the same folder like the exe. Add the location of the PDBs under File->Symbol File Path (CTRL+S).
Debugging symbol issues
If the symbols (PDBs) do not work as expected, use the
!sym noisy
command to debug the issue. This will display additional information about paths where WinDbg looks for PDB files.
If you change the symbol paths to fix the issue (using .sympath, .sympath+, .symfix or .symfix+), be sure to issue a .reload afterwards.
Checking correctness of symbols
If changing the symbol path still does not help, maybe the PDB does not match the executable (should not happen if you just compiled it). Just to be sure, you can use the symchk tool which comes with WinDbg.
Symchk /if <exe> /s <symbol path> /av /od /pf
/if = input is a file
/s = symbol file path
/od = all details
/av = verify
/pf = check if private symbols are available
or get ChkMatch which is a bit easier to use
ChkMatch -c <exe file> <pdb file>
Workspaces
(a question in the comments)
Don't worry about the workspaces and that WinDbg asks to save. You cannot understand the concept without reading about it.
Related
When I compile my swift framework MyFramework I makes so that Xcode produces MyFramework.framework (the compiled framework) and MyFramework.framework.dSYM (the dSYM file).
By running dwarfdump myframework.framework.dSYM/Contents/Resources/DWARF/MyFramework I've noticed that all the paths to the source files are absolute paths.
This makes it impossible to share these two artefacts (together with the source code) with my colleagues and allow them to use the compiled framework and being able to debug their code properly. More precisely they are not able to step-in inside the framework with the debugger.
For this reason they need recompile the framework which is very inconvenient.
Is there a way to modify the DWARF to edit these paths or even better to convince Xcode to use relative path in the DWARF file?
While I'm not aware of a way to change the paths stored in the dSYM or to make them relative, I can offer a way to work around the issue and be able to debug with those symbols on an arbitrary machine with source code in a different base path.
Once you find out what the original path is (e.g. /Users/rob/src/Project), and you have the code for that library in e.g. /Users/luka/Sources/Project, then you can issue this lldb command, which will replace for that session of the debugger the original path with your path:
settings set target.source-map /Users/rob/src/Project /Users/luka/Sources/Project
Unfortunately you'll need to run this command for each debugging session. To do that, you can create a breakpoint in your main, which runs that command and continues execution without stopping.
To find the original source path you can either use dwarfdump as you mention, or you can look up a symbol you know is in that binary from lldb with im loo -v -n MySymbol or through other parameters of the command (depending on the type of symbol you're trying to use).
I'm trying to debug an NDK project on Windows using Eclipse (Kepler), but GDB won't find the symbols for the .so file, because the direction of the slashes in the search path are incorrect. Using NDK r9 and SDK 22.2.1, when I try and run the application, GDB shows:
warning: Could not load shared library symbols for 64 libraries, e.g. /system/bin/linker.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
warning: Unable to find dynamic linker breakpoint function.
GDB will retry eventurally. Meanwhile, it is likely that GDB is unable to debug shared library initializers or resolve pending breakpoints after dlopen().
No symbol table is loaded. Use the "file" command.
No symbol table is loaded. Use the "file" command.
No symbol table is loaded. Use the "file" command.
The "No symbol table is loaded..." lines appear once for each breakpoint set in my library. The problem seems to be that GDB isn't finding the unstripped .so file, as the search path contains backslashes instead of forward slashes. If I pause the program and execute the following GDB commands, this is the output I get:
show solib-search-path
The search path for loading non-absolute shared library symbol files is C:\\Users\\Username\\Projects\\Project\\Android/obj/local/armeabi-v7a/.
info shared
From To Syms Read Shared Object Library
0x4003fff0 0x4006db40 Yes C:/Users/Username/Projects/Project/Android/obj/local/armeabi-v7a/libc.so
0x5bda8598 0x5bf5aa50 No C:/Users/Username/Projects/Project/Android/obj/local/armeabi-v7a/libProject.so
If I then update the solib-search-path to use forward slashes, I get this:
set solib-search-path C:/Users/Username/Projects/Project/Android/obj/local/armeabi-v7a/
warning: Could not load shared library symbols for 74 libraries, e.g. /system/bin/linker.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
warning: Unable to find dynamic linker breakpoint function.
GDB will retry eventurally. Meanwhile, it is likely
that GDB is unable to debug shared library initializers
or resolve pending breakpoints after dlopen().
info shared
From To Syms Read Shared Object Library
0x4003fff0 0x4006db40 Yes C:/Users/Username/Projects/Project/Android/obj/local/armeabi-v7a/libc.so
0x5bda8598 0x5bf5aa50 Yes C:/Users/Username/Projects/Project/Android/obj/local/armeabi-v7a/libProject.so
After which point GDB will successfully hit breakpoints in the native code. The gdb.setup file in the libs\armeabi-v7a folder has the line:
set solib-search-path ./obj/local/armeabi-v7a
But I'm not sure where this path gets changed into an absolute path. I'm guessing it's at that point that GDB uses the path with backslashes instead of forward slashes, but I'm not sure where that happens. I did try modifying the Android NDK build scripts that create the gdb.setup file, and even tried putting in a different path, but the output from show solib-search-path was just the same, so I'm not even sure GDB is using that search path. Has anyone come across this problem before, or does anyone know how I can get GDB to start up with the correct search path when I run from Eclipse?
I think this may have just been GDB not loading the symbols until a later time. I did have a delay before loading the project's .so, to allow GDB time to connect. I moved the delay until after the call to loadLibrary, and it seems to be picking up the symbols fine now.
I have a problem using 'xcopy' command.
I'm building a C# project with msbuild. At the end of the build, a batch file is called to copy my assemblies from Debug/Release to some other folders.
Here is the problem, my build fail and the error log is 'xcopy is not recognized as an internal or external command, operable program or batch file'.
The path is correctly set, xcopy do works from a windows command line and from the visual studio command line (the one set with the project environment).
I tried to set the path in the batch file but it doesn't help.
Any suggestion?
I'm using windows 7
Cheers :)
I encountered the same problem.
It seems to be a problem with the path environment variable within Visual Studio.
When I added a "path" statement to the beginning of my build event, it produced the following output:
PATH=
This seems to indicate that the path is empty within the VS build environment.
When I specify the full path to xcopy like this, the problem went away:
%systemroot%\System32\xcopy ...
I'm not sure what caused Visual Studio to lose it's path.
Set Environment variable PATH = %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\
This is not a problem with Windows 7 or 8. It's actually a problem with applications that update environment variables such as PATH.
The PATH is stored in the Registry as an "Expandable string value" (REG_EXPAND_SZ), but a lot of applications write it back to the Registry as a "String Value" (REG_SZ). If your path contains anything like %SYSTEMROOT%, this will not be expanded into C:\Windows (or whatever yours is) if the path is stored in a REG_SZ.
The fix is simply to edit your path manually from the control panel. You need to make a change (eg add a ; to the end of the path) and then apply it. This will fix up your path in the Registry to be a REG_EXPAND_SZ.
(Go to the System Control Panel and select Advanced System Settings. Edit the Path Environment variable in the lower box, and that should fix it.
You can tell whether your path is broken in this way by opening a command prompt and typing PATH. Your path will be listed. If you can see anything enclosed in % % then your path is not being expanded.
It happened to me after I updated one of my Visual Studio extensions, during which Visual Studio was closed and reopened by the updater. I could no longer properly build my project. I closed Visual Studio and reopened it and the problem went away.
I just experienced this for the first time with a batch file I use to copy an Access front-end app to the user's local machines. Their environment is a mix of Windows 7 & 8 and 32-64 bit machines. I noticed that the xcopy.exe was both in the System32 and the SysWOW64 folders and I wondered if there was some conflict. So -- I copied the xcopy.exe into the folder where the batch file resides and it now seems to be working. Just thought I'd share this.
Eileen
I also had a problem with xcopy (same error message) - with a very simple batch program that I use to backup files to a removable drive. Have been using that program for at least 5 years with never a problem. Then yesterday xcopy is unknown to Win7. The replacement of xcopy with %systemroot%\System32\xcopy at each instance solved the problem. Very strange.
Go to environment variable and correct PATh including ; in last.
It will work, this is not at all related to OS or Technology.
It's working for me, Not even need to restart OS, Just open new command prompt.
[Fixed for me]
After adding the correct paths to "Path" environmental variable it still doesn't work (for cmd and VisualStudio) (even after restarting the PC).
The problem was in broken register parameter:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment]
ParameterName=PATHEXT
I had the value .wlua;.|exe. Maybe was broken after installing something.
Everything works again after changing it to:
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
Hope this helps if nothing other works.
I try to install/run emacs on a Win7 64-bit machine after using it for years on a WinXP 32-bit machine and run into a problem I do not find any help for in the documentation or on the web.
Symptom:
when starting runemacs.exe for the first time it creates the file
*C:\Users\USER\My Documents.emacs.d*
as one would expect (for my administrator as well as for my user account)
and comes up operational
from the second start of runemacs.exe it breaks in the startup phase,
displaying the scratch buffer, ringing the warning bell and displaying in
bottom line the error:
File exists: c:/Users/USER/My Documents/.emacs.d/
buffer messages specifies:
make-directory: File exists: c:/Users/USER/My Documents/.emacs.d/
if runemacs was called with a file to open, i.e. because the file type was
associated with it and the file was opened to edit, the file is not open
and ready to be edited, but a file can be opened via the menu File->Open File...
but my configurations in the file
C:\Users\USER\My Documents.emacs
are not loaded
My goal:
I want to regain the way I used emacs on the old WinXP 32-bit system:
click a file associated with emacs, get it opened and ready for editing, get my configurations in .emacs loaded automatically, i.e. work with emacs seamlessly.
Checks done and failed attempts to fix this:
I tried the following newly downloded versions of emacs
emacs-23.4-bin-i386.zip
emacs-23.2-bin-i386.zip (the one I used on the WinXP)
I had the emacs directory containing the directory stucture (bin, etc, ...)
located at:
C:\Program Files (x86)\emacs-23.4\ (my preferred location)
C:\Emacs\emacs-23.4\
in the download directory, where I originally extracted it
My HOME variable points to:
C:\Users\USER\My Documents (default)
C:\Users\USER\My Documents\ (tried)
My PATH variable contains:
C:\Program Files (x86)\emacs-23.4\bin (default)
or the corresponding other locations which I tried
The ownership and permissions of my C:\Users\USER\My Documents.emacs.d
look OK:
owner is the USER (administrator or standard_user)
permissions grant Full Control
Having originally installed emacs to *C:\Program Files (x86)\emacs-23.4*
using the administrator account, I also tried to use user account installation
instead (to check for some non- obvious parameter/access permission not set
right if the admin account is uses for setup)
For the runemacs.exe executable I manually set the compatibility settings to
Windows XP (Service Pack 3)
default setting after unpacking: no compatibility setting enabled
I removed the private configuration file C:\Users\USER\My Documents.emacs
(inherited from my XP installation) to check whether it produces a screw-up
All that did not change a bit of the described symptom, i.e. either I screwed up
in testing the above and missed a particular setting which should work, or I am looking into the wrong direction...
It is still unclear to me whether this has anything to do with:
W7 64-bit vs. XP 32-bit
environmental parameter screw-up
emacs configuration (.emacs, .emacs.d) screw-up
general stupidity (of me ;-)
... and why is it has emacs a problem with it in the first place, that the .emacs.d directory already exists... That should be the standard case...
Any help and wisdom much appreciated.
First of all, nice question. The details and listing of what you've already tried is helpful.
Some points:
Don't have spaces in key paths (Emacs, and %HOME%). Generally, things work
fine. But when things break it's often hard to debug and trace back to the
fact that some package author didn't take spaces properly into account.
Set a HOME environment variable to your %USER_PROFILE%. Make it
%USER_PROFILE%/home if you must, but I use the former.
Start by running emacs without any customization.
runemacs -Q
When that works, add your customizations one at a time.
n.b. This answer is not relevant to the original question (which was about Windows), but may be useful to Unix users searching for this error message
You will get this error also if emacs does not have the correct permissions on the .emacs.d directory.
Check it
ls -ld $HOME/.emacs.d
And make sure the user you are running under has rwx permissions!
I got similar problems when I installed the new version of emacs on a new installation of the ubuntu 12.10. I get the problem fixed by chmod 777 .emacs.d, that is, as the previous post pointed out, the emacs does not have the access right to .emacs.d directory. Hope this help.
I'm trying to learn about reading dump files, so I made my small APP crush, and created a dump for that process from task manager.
I tried to open the .dmp file, both from VS10 and windbg.exe, and got an error that the symbol files are missing. I specified the path of the symbol files as the directory where the .pdb files are located :
..\Visual Studio 2010\Projects\CachedQueryTester\CachedQueryTester\bin\Debug
but I still get the same error, both on VS10 and windbg.exe,
Any Idea?
You may also need symbols from Microsoft , try to enter
0:000> .symfix
in windbg
From your configuration, you should not have to specify any debug symbol path, because the path of your symbols are stored in the executable. To be sure, you can open a Visual Studio Command prompt and type
dumpbin CachedQueryTester.exe /HEADERS
In the output, you should have a 'Debug Directories' entry containing the full path of the pdb.
If this is not the case, check you have specified to generate a PDB file (Configuration Properties / Linker / Debugging / Generate debug info);
You can also try to ask WinDbg for the location it looks for. In order to do this, open your dump file from within WinDbg, type '!symnoisy' and reload the symbols (.reload /u then .reload and kb). It will tell you the locations it looks for.