runtime: Exception.ToString() throws an exception when it encounters a frame that requires opening a regular PDB

The original complaint was avoiding an error (exception) when doing ToString() on an exception (which walks its stack. I am assuming there is no pushback on at least no failing. There is an interesting question on exactly what it does do to give the user a hint that their PDB is ‘wrong’. Just giving up on line numbers is not as good as giving a parenthetical diagnostic that the PDB is not a portable PDB).

Of course @mjsabby wants it to ‘just work’. I think we should at least understand the cost-benefit of that. Presumably the idea would be to make it work on Windows only. Note that this is what we do with perfCounters and I am sure other things that are hard to port to Linux. I think the ability to ‘just work’ on windows with Microsoft PDBs is useful (I think @danmosemsft scenario of using windows libraries without recompiling seems interesting, and we should understand how common it is likely to be).

My main concern is that line numbers in the exception trace really does ‘drag’ in a bunch of PDB reading stuff that otherwise the runtime is agnostic to. Ideally the runtime only has the hook, and it is up to other things (like an SDK installer), to wire into the hook (that is install the necessary DLLs).

So, I think it is reasonably to fix the error, and we should gather some data on who is likely to benefit from this (can we describe the scenario where people naturally generated Windows PDBs but want to run on .NET Core?). It seems like our desire to ‘converge’ .NET Core and desktop scenarios suggests that this will be important, but I don’t really have a feel for what we are expecting people to do at build time (if we force them to use new tools (which is sad), then I suppose forcing them to use portable PDBs it not much worse.

But my main suggestion is to fix the uncontroversial part first.

I am confused by this issue. Do I understand it correctly that:

1. If I run a .Net Core application with non-portable PDB on Unix, Exception.ToString() internally throws an exception, which is then caught here. As a consequence, the result of Exception.ToString() doesn’t have line numbers.
2. If I run a .Net Core application with non-portable PDB on Windows, line numbers are included in Exception.ToString().

To me, this sounds like a reasonable state to be in, especially if adding support for reading non-portable PDBs on Unix would take a lot of effort.

Adding some indication to the output that an exception was thrown seems reasonable to me, assuming it wouldn’t be too noisy.

---

What I did to see that my understanding is right:

1. Start on Windows.

2. dotnet new console

3. Specify <DebugType>Full</DebugType> in csproj to force non-portable PDB and add the following code to Program.cs:

   try { throw new Exception(); } catch (Exception ex) { Console.WriteLine(ex); }
   

4. dotnet publish

5. Verify that the PDB does not start with BSJB (it starts with Microsoft C/C++ MSF 7.00).

6. dotnet .\bin\Debug\netcoreapp2.0\publish\hwapp.dll prints the line number:

   PS C:\code\tmp\hwapp> dotnet .\bin\Debug\netcoreapp2.0\publish\hwapp.dll
   System.Exception: Exception of type 'System.Exception' was thrown.
      at hwapp.Program.Main(String[] args) in C:\code\tmp\hwapp\Program.cs:line 9
   

7. Switch to Linux (in my case, WSL Ubuntu), copy the publish directory over or use some shared file system.

8. dotnet bin/Debug/netcoreapp2.0/publish/hwapp.dll doesn’t print the line number:

   svick@Svick:/mnt/c/code/tmp/hwapp$ dotnet bin/Debug/netcoreapp2.0/publish/hwapp.dll
   System.Exception: Exception of type 'System.Exception' was thrown.
      at hwapp.Program.Main(String[] args)