Develop Reference

First time exception - System.pdb not loaded

I use VS2017 and I get the following when I hit F5
It happens for certain projects only, even if I disabled the Symbols support under VS options. Although in the past, for the same projects it used not to throw even with Symbol support enabled.
So, since I assumed this must be some kind of cached VS setting project specific, I deleted bin, obj, .vs , SymbolSource folders but the same.
If I enable Just My Code it does not throw, however this is not what I want since I cannot debug assemblies which I already have the symbols.
As far as I know even if Symbols Support is enabled it shouldn't throw if there isn't a related Symbol Server declared in VS Options.
This behavior is not specific only to System.dll but happens even if I attach to external processes which I do not have symbols, meaning that filtering with the Load Only Specified Module VS option again is not what I am looking for.
So, does anybody have an idea on how to avoid such annoying exceptions while allowing to utilize Symbol Support for other assemblies which I have configured.

It means that you want to step in to the
.net Framework source code:
http://referencesource.microsoft.com/setup.html
http://referencesource.microsoft.com/indexedpdbs.txt
Actually we also reported this issue to product team for VS 2017 before:
Stepping into .NET Source Still Doesn't Work
If you really want to avoid it, I suggest you disable settings like "Enable .NET framework source stepping" under TOOLS->Options->Debugging.
To debug .NET framework source code,we need to:
Disable just my code
Disable step over properties and operators
Disable require source files to exactly match the original version
Enable .NET framework source stepping
Enable source server support
So just use the contrary settings as above options, debug it again.
In addition, please enable the symbols server under TOOLS->Options->Debugging->Symbols Server, and enable the exception settings window, view the detailed exception messages, maybe you have to resolve the Exception firstly or get any helpful information from it.

Try to uncheck the debug hosting service.

None of the above worked for me because I was using external DLL which didn't have the PDB file with it. I found that when I removed all the breakpoints.
Go to Debug menu > Windows > Exception Settings (or press ctrl + alt + E)
Now check Common Language Runtime Exceptions or click Restore default (Refer screenshot):
So when it throws exception and you don't see it, it want to use the PDB file to store the stack trace but it didn't find it.

I had to check Enable native code debugging under Debug tab in project properties to get rid of this issue (Refer screenshot)

Debugging dump files in Visual Studio

I am using Visual Studio 2010 Professional Edition, and Windows Vista.
Firstly, I have this code. As you can see, it will crash the program!
using System;
namespace Crash
{
class Program
{
static void Main(string[] args)
{
string a = null;
if (a.Length == 12)
{
// ^^ Crash
}
}
}
}
The program will crash on the if statement. Now, I want to find out that it crashed on that if statement.
If I "Start without Debugging" from Visual Studio, Crash.exe crashes. It uses 1,356kb of memory. I get the Vista option of Close Program/Debug. If I choose Debug, I can open a new instance of Visual Studio, and it points me to a NullReferenceException on the if statement. This is good.
Now let me assume that it crashes on another computer, and I get them to give me a Dump File via Task Manager. It is 54,567kb. Why so big! It's vast! Anyway, I am less interested in that (slightly)
If I open that dump with Windbg, I get very little of use to my untrained eye:
Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\Richard\Desktop\Crash.DMP]
User Mini Dump File with Full Memory: Only application data is available
Symbol search path is: SRV*C:\SYMBOLS*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Server 2008/Windows Vista Version 6002 (Service Pack 2) MP (4 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS Personal
Machine Name:
Debug session time: Sat Jan 15 11:07:36.000 2011 (UTC + 0:00)
System Uptime: 0 days 4:24:57.783
Process Uptime: 0 days 0:00:05.000
........................
eax=002afd40 ebx=77afa6b4 ecx=002afd48 edx=00000001 esi=001cdaa4 edi=00000000
eip=77bf5e74 esp=001cda5c ebp=001cdacc iopl=0 nv up ei ng nz ac pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000297
ntdll!KiFastSystemCallRet:
77bf5e74 c3 ret
However, this is of less interest to me. As far as I can tell, I need to write commands in to get useful output, and Visual Studio is better.
So I open it with Visual Studio. I can choose to "Debug with Native Only", but I get lots of things that mean something to clever people like you, and I am not clever! I get these two screens:
So, my question:
How do I show Visual Studio to my source code?
Also, is there a way to get a smaller dump file? It seems ridiculously big, even after compressing. I don't understand why there couldn't be one which is only just a tiny bit bigger than the program's footprint, and still get a nice debugging, with the source code.

The much advertised feature that Visual Studio 2010 allows you to debug crash dump files and step through the managed source code comes with a gotcha: it works only for .NET 4.0 assemblies. Here are the steps:
Create a crash dump file on another computer using the Task Manager
Open the solution in VS2010
Open the .DMP file (File->Open...)
Click on Debug With Mixed (This will be visible only for .NET 4.0)
Source code will open and you will be able to inspect the exact cause and location of the exception
As far as debugging with native only is concerned Visual Studio is no more useful than WinDbg.

The tooling you are using here wasn't ever designed to troubleshoot crashing managed programs. Minidumps and Windbg is what you use to find out what's wrong with code written in C or C++. Pretty important tools, these are languages whose runtimes have no support for the kind of goodies you can get out of a crashing managed program. Like an exception with a stack trace.
The reason the minidump sizes are so different is because of the mini in minidump. By design, it was meant to capture a small snapshot of the process. The relevant argument is DumpType in the MiniDumpWriteDump function. There's really clever code in this function that can figure out what parts of the process state don't need to be recorded because you are not likely to use it in the debugger session. Which you can override by providing additional dump type flags. The minidump that Explorer generates has all of those flags turned on, you get the whole kit and caboodle.
Which is actually pretty important for a managed program. The heuristics used by this minidump creator is one that's only appropriate for unmanaged code. Debugging a managed program dump only works well when you include the entire garbage collected heap in the dump. Yes, that will be a large dump, mini doesn't apply anymore.
Your next problem is that you are getting the soul of the machine view from the minidump data. Your screen shots are showing the machine code. You happen to be located inside of Windows in those shots, note how ntdll.dll is on top of the stack. The mscorwks.dll entries are the CLR. Further down, out of view, you ought to see stack frames from your own code. You'll however see the machine code that was generated by the JIT compiler. Not your C# code.
There's a Windbg add-in called sos.dll that extends the command set of Windbg to be able to inspect managed data. Just google "sos.dll" to get good hits. This is however still a looong way away from the kind of debug experience you'll get out of the Visual Studio debugger. Which is intimately aware of managed code, very unlike Windbg or the VS debugger that can load minidumps. Sos was really designed to troubleshoot CLR bugs.
There were no dramatic improvements in VS2010 other than the minidump info page you now see. Which really doesn't do much at all. I suspect the Debugger Team to have this on their todo list, there are surely some fundamental problems to overcome. Particularly in the minidump format and creation code. Use connect.microsoft.com to provide feedback, they pay attention to it and let votes affect their priority list.

You should be supplying the related pdb (program database) file to the debugger so it can load the symbols. Also to get a better view, use Microsoft Public Symbol server. This article contains information on it.

C# SystemNullReferenceException in WindowsForms

I'm having the following error when closing a form in an application
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.
***** Exception Text *******
System.NullReferenceException: Object reference not set to an instance of an object.
at Infragistics.Win.UltraWinGrid.UltraCombo.get_Text()
at Infragistics.Win.UltraWinGrid.UltraCombo.OnEnter(EventArgs e)
at System.Windows.Forms.Control.NotifyEnter()
at System.Windows.Forms.ContainerControl.UpdateFocusedControl()
I'm almost sure that this has something to do with the fact that I'm using multithreading to populate some data, but my problem is that I'm not able to determine the place in which the call to the method is being made.
A .Net framework appears and I can only click continue or close, but what I really wanted was an application crash to determine what is causing the error. This is even more complicated because it only happens with compiled code. Do you know any profiler or technic to catch the error?
Can I attach the debugger to my exe to capture the method throwing the error?
UPDATE:
What I really want is to enable JIT debugging and have access to the stacktrace tho determine the cause of the error, I've done that by adding the
<system.windows.forms jitDebugging="true" />
to the config file as described in MSDN to my config file, but now I'm not getting any error at all.
Bottom like, can I do anything else for the framework give additional details about the error?

You can set Visual Studio up to break on specific types of exceptions. There is an Exceptions dialog under the Debug menu. Just check the exception you wish to break on and run the code with the Visual Studio Debugger attached.

How to get line number(s) in the StackTrace of an exception thrown in .NET to show up

MSDN says this about the StackTrace property of the Exception class:
The StackTrace property holds a stack
trace, which you can use to determine
where in the code the error occurred.
StackTrace lists all the called
methods that preceded the exception
and the line numbers in the source
where the calls were made.
So I know that this information is available. How do I get the line numbers to actually show up in the stack trace? My code is throwing an exception in a very difficult and complex piece of code that goes through TONS of objects, so I don't want to step through a bazillion times to see where the exception is happening. The stack trace of the exception only shows method signatures and no line numbers.

To get the line numbers in the StackTrace, you need to have the correct debug information (PDB files) alongside your dlls/exes. To generate the the debug information, set the option in Project Properties -> Build -> Advanced -> Debug Info:
Setting it to full should suffice (see the Advanced Build Settings Dialog Box docs for what the other options do). Debug info (ie. PDB files) are generated for Debug build configurations by default, but can also be generated for Release build configurations.
Generating PDBs for release builds enables you to ship you code without the PDBs, but to drop the PDBs next to the dlls if you need line numbers (or even to attach a remote debugger). One thing to note is that in a release build, the line numbers may not be entirely correct due to optimisations made by the compiler or the JIT compiler (this is especially so if the line numbers show as 0).

You could try the following, given there is a pdb file for the assembly:
try
{
throw new Exception();
}
catch (Exception ex)
{
// Get line number from the stack trace's top frame for the exception with source file information
int linenumber = (new StackTrace(ex, true)).GetFrame(0).GetFileLineNumber();
}

You have to build the project with pdb files enabled and make sure your deploy the pdb files with your application. You can check if pdb files are in fact being built for you configuration by right clicking on the assembly you require pdb files for, then heading to Properties > Build > Advanced and making sure that under Output Debug Info is set to full.

If you have a web application or web service project using VS2012 or later, changing the build settings will not work. Instead, you should follow the advice in this article:
Visual Studio 2012 Website Publish Not Copying .pdb files
Specifically, you should include the following setting in the
<YOUR_PROJECT>\Properties\PublishProfiles\*.pubxml
file(s) for your project:
<PropertyGroup>
<ExcludeGeneratedDebugSymbol>False</ExcludeGeneratedDebugSymbol>
</PropertyGroup>

Further to the other great suggestions, we were deploying to IIS. We had a staging server and a production server. They appeared identical except staging gave us line numbers and production did not. It turned out that there was an extra DLL in the bin directory of production (it happened to be SqlServerSpatial.dll fwiw) and once it was moved to the system directory line numbers started appearing on production.
The lesson was to ensure that the bin directory of production matches the bin directory of development in every respect (except for XML files).

Seem to have found the solution.
On VS2010 at least, with Output Debug Info set to full I also did not get line numbers within the exceptions. The trick it seems was to turn on line numbers within the editor. (Tools -> Options -> Text Editor -> All Languages -> General -> Display -> Line numbers)
Now exceptions show up with line numbers.

What is the usage of pdb's (Program Debug DataBase)?

When compiling a library or an application (e.g a Console Application in the Visual Studio IDE), in the Debug folder of the application, apart from the .dll or .exe, there will be one more file with extension ".pdb".
What is the exact usage of this .pdb file?

PDBs contain debugging symbols, so you can ship a compiled binary to your customer without exposing your source code algorithms and other private details to them.
If your app goes wrong on a customer site, you can get a crash dump from them (using DrWatson), bring it back to your dev workstation and debug the crash, the debugger will use the symbols file in conjunction with the crash to show you the source code, data structures etc. In many cases, all you have to do is open the crash dump and the debugger will take you directly to the source code of the exception, and show you variables and threads too.
That's the primary use of them, they're invaluable when a customer reports a crash. The things you need to know about using them though - they are only valid for the build that created them, so if you recompile, your symbols file is next to worthless.
John Robbins has an excellent article why you would use them.

John Robbins has written some really great articles on PDBs lately:
PDB Files: What Every Developer Must Know
Visual Studio Remote Debugging and PDB Files
How Many Secrets do .NET PDB Files Really Contain?
Do PDB Files Affect Performance?
Correctly Creating Native C++ Release Build PDBs

PDB's allow debugging of applications, for examlple when they crash or if you have a minidump. They also allow you to find more detail about errors when outputting exceptions to logging (they will give a more complete stacktrace with line numbers rather than just showing the name of the function where the error occurred).

PDB's are useful when you want to do remote debugging as well.
Keeping the PDB's together with your installed application makes it possible to hook up visual studio remotely to the client's production environment and debug the application when necessary.

Well you've given yourself a big clue in your title.
It's the file Visual Studio needs to be able to debug your application.
This MSDN page has more information.
A program database (PDB) file holds debugging and project state information that allows incremental linking of a Debug configuration of your program.

As far as i know, they contain debugging information, such as line numbers, variable names, etc.