I followed the steps described here to break when a function defined in an external dll is hit, however its not working for me. Maybe I am missing a setting. How can I get it to work?
Checklist:
- Enable just my code is disabled
- Symbols for external dll (System.Data.Entity.dll) appear to have been loaded (see below)
EDIT: the answer is to compile the code as 32 bit. It worked for me, can't say if it will work for others.
Some notes: There is a useful tool to know about. Its called srctool.exe. It comes with Debugging Tools for Windows and got installed under c:\Program Files\Debugging Tools for Windows (x64)\srcsrv on my machine. You can run it on a pdb file and it will tell you whether file has been source indexed or not. If the pdb file is source-indexed, then there is a link embedded in the pdb file which points to a location from where the source code can be fetched. E.g., I see this output from srctool.exe:
[f:\dd\ndp\fx\src\DataEntity\System\Data\Objects\DataClasses\RelatedEnd.cs] trg: http://referencesource.microsoft.com/source/NET/4.5/net//ndp/fx/src/DataEntity/System/Data/Objects/DataClasses/RelatedEnd.cs/550320/RelatedEnd.cs
What if pdb file is not source indexed? Does it mean VS will not be able to show you the source, step-in etc.? I think so, though I am not an expert. I found this link to be semi-useful.
Anyway, coming back, for me, fetching code from the embedded link in pdb file meant running this command (VS will give you a popup where it will ask you to run the command; if it fails you won't know; only way to know if it succeeded is to run it yourself from a console) which gave an error.
tf.exe view /version:550320 /noprompt “$/[omitted]/[file].cs” /server:http://[omitted] /console > [file.cs]
To get around this limitation, I manually downloaded .net framework source code from http://referencesource.microsoft.com/netframework.aspx. There was a problem here also: the file gets downloaded as .aspx which doesn't do anything. Turns out you have to rename to .msi. Then run the executable. See this link: http://social.msdn.microsoft.com/Forums/en-US/refsourceserver/thread/f17c11c1-72f6-4529-bafe-5a1d79b72bd7
I just can't believe how many issues I ran into.
Related
I want to step into the DevExpress XAF code using the debugger.
I have asked about it here but am having problems spotting what I have done wrong.
VS2019 16.2.2
Dev Express XAF 19.1.5 Winforms project
The break point is in Program.cs
at
winApplication.Start
which is in
DevExpress.ExpressApp.Win.WinApplication
I downloaded the .pdb files and set up the Symbols
I un-checked Tools->Options->Debugging->Enable Just My Code
At the breakpoint Debug->Windows->Modules shows that the Symbol file for mscorlib.dll is loaded.
Exception settings are
[Update]
Lance Li pointed out the cannot find or open the pdb file message
When I select Symbol Load Information it mentions the location is
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\DevExpress.Utils.v19.1\v4.0_19.1.5.0__b88d1754d700e49a\DevExpress.Utils.v19.1.pdb: Cannot find or open the PDB file.
I tried clicking the load all symbols button in the symbols screen but it did not help.
I attempted to locate the pdb but got a message
A matching symbol file was not found in this folder
I tried suspending Resharper and that did not help.
[Update]
I noticed that it is looking for the file in the GAC
I see that there is a copy of mscorlib.pdb in d:\pdb\19.1
Could it be that that somehow re-arranges something to expect to find the Dev Express .pdbs in the GAC?
The source code is on GitHub
[Update]
In the DevExpress question Dennis points out that when he hits F11 Visual Studio asks for a source code path. I think this happened once for me I have selected the default path. Now Visual Studio no longer asks.
I tried re-cloning the application but it did not help.
I tried opening up with VS2017 but that did not help.
[Update]
I installed on to a different computer
then at the break point I received a dialog box to select the source code.
I located the source at
Directory of C:\Program Files (x86)\DevExpress 19.1\Components\Sources\DevExpress.ExpressApp\DevExpress.ExpressApp\DevExpress.Persistent.Base
Then I was able to step through the Dev Express code on the second computer.
Now to figure out how to correct the behaviour on the first computer.
[Update]
I was able to get the Find Source dialog up by the following method.
Run to the break point , then select Debug -> Windows -> Modules.
Then right click an unloaded module and un-check Always Load Automatically.
After that when I ran again I got the dialog allowing me to locate the source.
My problem was that Visual Studio was looking in the wrong place for the source.
Further to that, because it had been told to look in the wrong place automatically then I did not receive a dialog asking me to locate the source.
So as to receive the Find Source Dialog , the trick was to unckeck the Always Load Automatically option.
To get at this option, I ran to the break point and then selected Debug -> Windows -> Modules. Then right clicked an unloaded module and un-checked Always Load Automatically.
A different way could have been to add the correct path to the Solution->Properties->Common Properties-> Directories Containing Source Code
I have a Visual Studio solution which I'm trying to build using the Incredibuild tool. Two of the projects in the solution work in tandem - the first project (we'll call it "Project A") builds an executable (foo.exe) which can parse a data file in the second ("Project B") to generate some header files.
Obviously there is a dependency on Project A defined in Project B. If I use Incredibuild's Rebuild Project option on Project B, it correctly builds Project A and foo.exe is successfully built. Project B has a custom build tool file which should cause foo.exe to be ran with a command-line argument to the file it's supposed to parse. However, trying to launch foo.exe in this way always returns an error:
CustomBuild:
Running Foo
'path to executable\foo.exe' is not recognized as an internal or
external command, operable program or batch file.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5):
error MSB6006: "cmd.exe" exited with code 9009.
Interestingly, if I then use Incredibuild to build only Project B (i.e. using the Build Project option), everything is ok - it correctly picks foo.exe from the location it was built to on the previous, failed, build. This makes me think that the path, at least, must be ok.
Can anyone suggest why the executable cannot be ran as part of the rebuild? Is it a timing issue, e.g. Project B commences before foo.exe is known to the file system??
It all works under Visual Studio's regular (re)build. It's just the Incredibuild rebuild which fails. Note that I'm doing all of this through the Visual Studio IDE, not from a command line.
Edit: this is the freebie version of Incredibuild that I'm using (the one which comes with Visual Studio), so all of the build is on the local machine.
I contacted the Xoreax technical support about this in the end and they told me that this is a "rare but known issue that is related to one of our extra accelerating features".
Their first suggestion was writing an executable which simply sleeps "for a few milliseconds" and having that run as part of the custom build tool post-link. This did indeed solve the immediate problem, but the solution I'm building has numerous similar problems and adding this delay in everywhere quickly became tedious and didn't always work. It felt like a fudge anyhow.
So I asked if this behaviour can be toggled to off, and indeed it can. In Visual Studio the Incredibuild menu has an Agent Settings option, and from the invoked dialog's Visual Studio Builds|Advanced page it's a simple case of unchecking the Enhance throughput using out-of-order tasks spawning option.
Case closed.
There are options how to offload or intercept custom tools during your build process. Try to look onto "c:\program files (x86)\IncrediBuild\Samples"
Using Visual Studio 2003 Professional under Windows 7 SP1 (64 bit), compiling from the command line, I get a fatal error C1074: IDB is illegal extension for PDB file. The documentation on this error is sparse to put it lightly. The incredibly odd thing about this is that, utilizing the same build script on the same computer but under a different account does not generate this error.
My first guess was that something in the environment variables is causing this conflict, but doing a diff between them for the two accounts, and modifying PATH and INCLUDE to be the same does not fix the error.
Does anyone have a fix for this error, or any idea what actually triggers it? None of the files are being compiled with a /Z switch of any kind, so as far as I can tell, no PDB files should ever actually be generated (and on a successful build, no IDB OR PDB files are generated that I can see).
I was experiencing the same problem with solutions on Windows 7 x64 and Visual Studio 2005 Pro (SP1).
Symptoms
I am using Visual Assist X (currently build 2007). So in my case all I needed to do was to disable IntelliSense by renaming feacp.dl inside C:\Program Files (x86)\Microsoft Visual Studio 8\VC\vcpackages to something else. That fixed the crash at startup (probably unrelated to the issue the OP encountered).
After that the Debug configuration gave me loads of
fatal error C1033: cannot open program database ''
errors, one per file compiled by cl.exe.
With the Release configuration I got
fatal error C1074: 'IDB' is illegal extension for PDB file: <filename>
i.e. the one about which the OP was asking.
Solution
I found the solution more or less by accident elsewhere, reported for VS 2003. In a sense it's the opposite of Luke's answer.
Fatal Error C1074
This error has been reported to occur if the Windows 7 machines have
Windows XP compatibility mode turned on. To resolve the error, turn
off the Windows XP compatibility mode and recompile the solution.
Should you have other issues check the MSDN forums for more help. Its
not the source it sounds more like your settings with VS. I've never
run across this problem before so I'm little help.
That prompted me to check out the settings for devenv.exe (in my case under C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\IDE). It looks like this:
In my case it was set to be compatible with Windows 2003 Server as depicted in the above screenshot. However, the compatibility must be turned off! (checkbox unchecked)
Also make sure to check out and correct the settings for all users by clicking the second highlighted button (UAC prompt will show up if you aren't already running privileged).
This solved the problem for me and I can avoid running VS 2005 Pro elevated all the time.
From information I've gathered on MSDN about issues similar, but not exactly the same:
Since it compiles with no other change than the user account, I believe there's a chance that it could have something to do with the user accounts permissions. Check and see the differences between the users permissions in VS's settings, and in Windows User Settings. The first thing I would try though is to close VS, reopen with Run As Administrator using the account that WON'T compile and see what happens.
In the attempt of sharing the solutions of some of my troubles, and in the hope of sparing them to others, I had the same issue trying to compile a legacy solution in VS2005/SP1 inside a Win8-x64 machine.
No matter what I tried to do, it always stopped there complaining about the illegal IDB extension...
On the other side, the very same solution compiled flawlessly in my previous Win7-x64 box, when run "elevated".
After much struggling I found that I had to use Win8 "Program Compatibility Assistant" (or whatever is named in the english version - my OS is using a different language) and tell it to run VS2005 in a Win7 elevated environment. After that, the obscure "IDB is illegal" error disappeared at once!
Hope this will help someone =)
I've got a Windows minidump (C code) and a corresponding exe file. Unfortunately, I don't have the exact matching .pdb files, but I do have .pdbs that contain the exact same code just built at a different time. In Windbg, I can use:
.symopt+0x40
To tell it to load anything, even mismatched symbol files. This works great in this particular instance, and I'm able to get a proper call stack. I'm just curious as to whether or not Visual Studio has any such feature. We use pretty much every different version of VS here, so it doesn't matter which version it might be in. Thanks.
Try this utility:
ChkMatch utility can be used to check whether an executable and debug information file match. It can also be used to enforce matching between an executable and debug information file, if they are compatible.
For more information about debug information matching and related issues, see this article.
Supported debug information formats: DBG, PDB 2.0, PDB 7.0...
There is no override, but the poster to this question found a way to modify the PDB files to make them match the EXE.
Thanks to one of the comments on the
first answer, I checked out a link to
the pdfs of the book "Undocumented
Windows 2000 Secrets: A Programmers
Cookbook". And the author goes into
great detail about the pdb file
format. As I said before, I had
already loaded the pdb into a hex
editor and flipped some bits around
appearing that I made the
age/signature match, but it didn't
work. Well, after using the utility
from the W2k secrets book to "explode"
the pdb into the included streams, I
found out that they hide another
reference to the age in stream
3!!!!!!! Once I flipped that one as
well, it matched up in windbg.
Not sure if you want to go to this much trouble, but it looks like it can be done. If this is for production support then it could be worth your while.
Visual Studio and Windbg match pdbs by comparing the timestamps in the Executable header with timestamps store in the pdb file. You can view the timestamp by running dumpin /headers .
I haven't used chkmatch but modifying either the exe or pdb to match each other should work fine.
Be aware that this technique may not be enough to debug your binary. John Robbins in his book 'Debugging Windows' (which I can recommend) mentions that he's seen different build results from the identical source tree built at almost identical times.
Always build pdb symbols with your builds (including release builds) and archive them alongside the build products and include the .map file for good measure.
According to this post its possible to use sos windbg commands as well in visual studio. But i am not sure if ".symopt" also falls into this category.
I'm told that in VS2019 (16.7 .. 16.8 ballpark) that they switched to a multi-threaded PDB file generator to speed that up.
A side effect is that sections of the file, being generated on different threads, may end up in a different order in the file.
Bottom line, it is even more important than before that you use the PDB that was built with the EXE and no other.
I have reinstalled my computer with Windows 7, and Eclipse 3.5.1 (Galileo).
The weird thing is that I can not see any files that Eclipse produces.
I can not find the workspace, can not find the files from the SVN after check out.
It seems like Windows 7 can not read the files produced by Eclipse ... wierd
What could be the reason for this?
Where do you have Eclipse installed? Where is your workspace?
In Windows 7 (Vista, actually), a lot of security policies that existed only on paper in earlier versions of Windows, are now actually enforced by the operating system. For example, according to Microsoft's documentation, it has been pretty much illegal to write to C:\Program Files for decades now, but if you actually tried it, it still worked. Not anymore. As of Vista, C:\Program Files is off-limits.
However, in order not to break existing (broken) applications, Microsoft introduced filesystem virtualization. If an application tries to write to C:\Program Files, it gets silently redirected to C:\Users\%Username%\AppData\Local\VirtualStore\Program Files. So, this specific application sees all the files it created or changed in C:\Program Files, but other applications, and this includes the Explorer, see only the unchanged / empty directory.
This does not just apply to C:\Program Files but also to other system directories as well. Also, it applies to system parts of the registry, like HKEY_LOCAL_MACHINE for example.
In order to sidestep all of this, I simply installed my copy of Eclipse in %LocalAppData%\eclipse (that's C:\Users\%Username%\AppData\Local\eclipse) and created my workspace in %AppData%\eclipse (that's C:\Users\%Username%\AppData\Roaming\eclipse). That Just Works™.
You can launch eclipse with the -showlocation option, which will display the path of the workspace in the title bar.
(See this eclipse.ini for instance)
From there, you can check if you find that workspace, and its eclipse projects within it.
You can also configure your shortcut: