C# exceptions not showing filename/line numbers (PDB issue?)
-
Hi, I'm developing an Explorer bar using VS.NET 2003 (C#) on Windows XP. For some time, I've noticed that I don't have filenames and line numbers appearing in my exceptions' stack traces. On the other hand, debugging with breakpoints, etc. seems to work fine in VS.NET 2003. I can't understand why this isn't working -- and I think it used to work, perhaps under VS.NET 2002, but maybe not. The information doesn't appear in exceptions when running under VS.NET or when not. I am running my Explorer bar (which is a class library, not an application) on the same machine (and user account) which built the library. The PDB file is accessible to me, and its location does match the location in the assembly. I am making Debug builds, and I do have "Generate debugging information" enabled. As far as I can tell, the PDB and DLL files are equally fresh and the same version? Any tips? Is this a known bug? It's driving me batty trying to locate an exception in code blocks without any help from line numbers. Thanks! Arun
-
Hi, I'm developing an Explorer bar using VS.NET 2003 (C#) on Windows XP. For some time, I've noticed that I don't have filenames and line numbers appearing in my exceptions' stack traces. On the other hand, debugging with breakpoints, etc. seems to work fine in VS.NET 2003. I can't understand why this isn't working -- and I think it used to work, perhaps under VS.NET 2002, but maybe not. The information doesn't appear in exceptions when running under VS.NET or when not. I am running my Explorer bar (which is a class library, not an application) on the same machine (and user account) which built the library. The PDB file is accessible to me, and its location does match the location in the assembly. I am making Debug builds, and I do have "Generate debugging information" enabled. As far as I can tell, the PDB and DLL files are equally fresh and the same version? Any tips? Is this a known bug? It's driving me batty trying to locate an exception in code blocks without any help from line numbers. Thanks! Arun
When you debug your shell extension, are you debugging a new instance of the shell (explorer.exe)? If the release assembly was registered and the shell invoked it it will continue to use it until the reference count is zero. The only way to do this is kill your shell or be sure to start a new shell when debugging. So long as you're on the same machine, the PE/COFF header (not the assembly) will point to the path of the PDB for debug builds). Since you're sure that it's pointing to the right place, I figured the release version might be registered and running currently. Otherwise, I can't think of any reason besides your debugging environment being hosed. If you're still getting runtime exceptions (which shouldn't happen in production code, of coruse) that prompt to start a debugger, I doubt this is the case. If none of the above are the case, when debugging your app, look at the Output window. Do you see where it loads your assembly? Does it say "Symbols loaded" or something similar, or that they can't be found?
Microsoft MVP, Visual C# My Articles
-
When you debug your shell extension, are you debugging a new instance of the shell (explorer.exe)? If the release assembly was registered and the shell invoked it it will continue to use it until the reference count is zero. The only way to do this is kill your shell or be sure to start a new shell when debugging. So long as you're on the same machine, the PE/COFF header (not the assembly) will point to the path of the PDB for debug builds). Since you're sure that it's pointing to the right place, I figured the release version might be registered and running currently. Otherwise, I can't think of any reason besides your debugging environment being hosed. If you're still getting runtime exceptions (which shouldn't happen in production code, of coruse) that prompt to start a debugger, I doubt this is the case. If none of the above are the case, when debugging your app, look at the Output window. Do you see where it loads your assembly? Does it say "Symbols loaded" or something similar, or that they can't be found?
Microsoft MVP, Visual C# My Articles
Thanks for responding. I do see "Symbols loaded" for my assembly when debugging my assembly, but even still, the line numbers don't appear in the exception's StackTrace. I'm pretty sure that I'm using the Debug build, as I make a point of not popping up exception-laden message boxes in the release builds. I even tried rebooting my computer yesterday after building and installing a new Debug release of my browser bar.... just in case. I started a new solution for a Windows application and was able to get line numbers in the stack trace, so at least I know that the problem is limited to my solution.
-
Thanks for responding. I do see "Symbols loaded" for my assembly when debugging my assembly, but even still, the line numbers don't appear in the exception's StackTrace. I'm pretty sure that I'm using the Debug build, as I make a point of not popping up exception-laden message boxes in the release builds. I even tried rebooting my computer yesterday after building and installing a new Debug release of my browser bar.... just in case. I started a new solution for a Windows application and was able to get line numbers in the stack trace, so at least I know that the problem is limited to my solution.
If you took many of the defaults when installing VS.NET (or have installed the Platform SDK), you should have a utility called dumpbin.exe. If you do, type
dumpbin.exe /pdbpath _<dll path>__and see where it thinks the PDB file is located. If it uses a relative path (and I think the PATH directories can contain it, too...don't remember off the top of my head), try moving the PDB file into the same path as the executable (or try another PATH directory). Also make sure that your assembly is registered usingregasm.exe /codebase(registering this from the project options uses this switch too).Microsoft MVP, Visual C# My Articles_
-
If you took many of the defaults when installing VS.NET (or have installed the Platform SDK), you should have a utility called dumpbin.exe. If you do, type
dumpbin.exe /pdbpath _<dll path>__and see where it thinks the PDB file is located. If it uses a relative path (and I think the PATH directories can contain it, too...don't remember off the top of my head), try moving the PDB file into the same path as the executable (or try another PATH directory). Also make sure that your assembly is registered usingregasm.exe /codebase(registering this from the project options uses this switch too).Microsoft MVP, Visual C# My Articles_
Okay, there's the ticket! dumpbin.exe was telling me that the PDB path was relative (.\). So I copied my PDB file into the GAC, right next to my DLL, and it worked. I didn't really expect that to work, but I guess the GAC is more lenient than it seems. What does the
/codebaseswitch get me? I'm starting to question my current practices, even though they've been working. I install my assembly like so:gacutil /nologo /if VisIT.dll regasm VisIT.dllAccording to C# in a Nutshell, I shouldn't use/codebaseif the assembly is in the GAC or if I plan to add it to the GAC. I wonder if I need it in the GAC. I thought I did -- or that it seemed like a good idea -- since this is for a shell extension. Thanks, Arun -
Okay, there's the ticket! dumpbin.exe was telling me that the PDB path was relative (.\). So I copied my PDB file into the GAC, right next to my DLL, and it worked. I didn't really expect that to work, but I guess the GAC is more lenient than it seems. What does the
/codebaseswitch get me? I'm starting to question my current practices, even though they've been working. I install my assembly like so:gacutil /nologo /if VisIT.dll regasm VisIT.dllAccording to C# in a Nutshell, I shouldn't use/codebaseif the assembly is in the GAC or if I plan to add it to the GAC. I wonder if I need it in the GAC. I thought I did -- or that it seemed like a good idea -- since this is for a shell extension. Thanks, ArunThe
/codebaseswitch tells regasm.exe to register the full path to the assembly in the registry. Since your assembly is in the GAC, you really don't need this (and I would recommend against it). IMO, you should refrain from testing assemblies in the GAC. Until you get your explorer bar working, just select the option in your project settings to register it (again, this uses the/codebaseswitch or at least duplicates the behavior) and test against that until you're ready to deploy it with an installation or something. Sure gets rid of problems like this and keeps your GAC clean, especially if you're using automatic versioning (using the asterisk in theAssemblyVersionAttribute), which I've learned causes more problems than not (especially large solutions where you update and redirect assembly bindings regularily).Microsoft MVP, Visual C# My Articles
-
The
/codebaseswitch tells regasm.exe to register the full path to the assembly in the registry. Since your assembly is in the GAC, you really don't need this (and I would recommend against it). IMO, you should refrain from testing assemblies in the GAC. Until you get your explorer bar working, just select the option in your project settings to register it (again, this uses the/codebaseswitch or at least duplicates the behavior) and test against that until you're ready to deploy it with an installation or something. Sure gets rid of problems like this and keeps your GAC clean, especially if you're using automatic versioning (using the asterisk in theAssemblyVersionAttribute), which I've learned causes more problems than not (especially large solutions where you update and redirect assembly bindings regularily).Microsoft MVP, Visual C# My Articles
Okay, I'll try to avoid the GAC for now, even though it's been okay for me for the past year. ;-) For a short while, I was trying out automatic versioning, but then I turned it off because my installer used a hardcoded assembly version number, and I never got around to finding a dynamic workaround. Thanks for your helpful persistence.
-
Okay, I'll try to avoid the GAC for now, even though it's been okay for me for the past year. ;-) For a short while, I was trying out automatic versioning, but then I turned it off because my installer used a hardcoded assembly version number, and I never got around to finding a dynamic workaround. Thanks for your helpful persistence.
If you're using the Windows Installer project in VS.NET, add the output of your project to the installer and it is updated whenever you recompile your C# project (it becomes a dependency of the installer project). I'm not saying the GAC doesn't work, I'm just saying that it can lead to problems until you're done testing. You've already had one. If you use automatic versioning you'll have lots of assemblies (differing only by version) in your GAC. It doesn't hurt anything, but it sure clutters up the GAC. It's just a recommendation that's not uncommon when debugging applications, especially in larger teams.
Microsoft MVP, Visual C# My Articles