Thanks for the article! It's worth noting that

1. the address you have to add in Visual Studio's Options under Debugging | Symbols is http://localhost:33417/ - this cannot be seen on the images because they are too small to read.

2. You need to click the green "Start Symbol Server" button on the DotNetPeek toolbar before you start debugging. If Visual Studio is trying to connect to the Symbol Server when it's not running, it will spend 5 seconds trying to load symbols for each and every DLL, failing every time.

3. Even if you tell dotPeek to generate PDBs for every DLL - which is very slow at first, but symbols are cached - it won't generate PDBs for DLLs it can't find, and on my PC dotPeek weirdly couldn't find any .NET Core DLLs at first, but then later it was suddenly able to find all of them. If it can't find things on its own, you'll have to add them manually to the dotPeek Assembly Explorer.

4. I found that Visual Studio was deciding not to consult the Symbol Server for DLLs that previously failed to load. In my case, I was able to fix this problem just by restarting Visual Studio. In dotPeek, you can see whether or not dotPeek is receiving requests for PDBs: (i) go to Windows|Pdb Generation Status to open the status window, (ii) click the Clear List button (if not already empty) (iii) restart the Visual Studio debugger and, if nothing appears in "Project/Pdb Generation Status", it means Visual Studio isn't sending requests.

See also: the dotPeek documentation about the Symbol Server: https://www.jetbrains.com/help/decompiler/Using_product_as_a_Symbol_Server.html#possible-problems-and-solutions