Unhandled exception in symbol serving

I've been unable to use the symbol server since updating, I do notice that I have this error message logged. And also if i try browse to the path i think the symbols should be at I can see a message "Object reference not set to an instance of an object."
Any help on what's causing this :)?

System.NullReferenceException: Object reference not set to an instance of an object.
at Inedo.ProGet.WebApplication.SimpleHandlers.SymbolServerHandler.<GetIndexedPdbAsync>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at Inedo.ProGet.WebApplication.SimpleHandlers.SymbolServerHandler.<ProcessRequestInternalAsync>d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Inedo.ProGet.WebApplication.SimpleHandlers.SymbolServerHandler.<ProcessRequestAsync>d__2.MoveNext()

Product: ProGet
Version: 4.0.4

It looks like this is a result of a bad/corrupt symbols file; basically it's failing while trying to enumerate a symbol that is specified in the index.

Any suggestions on what to check? Where will the symbols files be stored on the server? The symbols worked before the upgrade

Hmm. actually, sorry I must have missed that -- "upgrade"?

Are you using the v4.0 beta? We can definitely look a bit closer, could be resulting from some nonfunctional library change. The symbol stuff is quite sensitive.

Well it worked in approximately May, then I did an update in December to 3.8.6, it was noticed that it wasn't working in January, so I tried 4.0.4 but that didn't help. I do notice there is a fix about symbols servers in the list between May and December

There were probably a few between May/Dec, there wasn't anything that would have changed on the code side in v4.

However, looking further, this particular issue is a configuration problem.

You can fix this by just adding targetFramework="4.5" to the httpRuntime element on the web.config file.

It works! Thanks for that mysterious fix :)

Oh dear spoke too soon. Now I get this when browsing to the main proget page

[NullReferenceException: Object reference not set to an instance of an object.]
Inedo.Web.PageFree.IInedoPageExtensions.RedirectAndCompleteRequest(IInedoPage page, String url) +23
Inedo.ProGet.WebApplication.Pages.RootPage.ValidatePrivileges() +534
Inedo.ProGet.WebApplication.ProGetHttpModule.ValidatePrivileges(HttpApplication app, IHttpHandler handler) +78
Inedo.ProGet.WebApplication.ProGetHttpModule.PostMapRequestHandler(HttpApplication app) +751
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +91
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +164

I think that's another v4 bug, related to some broken redirects w/ anonymous...

You should be able to work-around by going to /log-in URL directly, then logging in.

Should a repair install fix these? I can try it

No, definitely not. It's a bug w/ the beta version and anonymous authentication redirects.

I've tried restoring my database and going back and nothing works still.

If i browse to

my-server/symbols/default/name.of.pdb/symbolguidandage/name.of.pdb

i get the pdb for the corresponding package.

Visual Studio however is saying

SRCSRV: D:\wheremycodelivesonbuildserver\blahblah.cs not indexed
SRCSRV: Source server cannot retrieve the source code for file 'D:\wheremycodelivesonbuildserver\blahblah.cs' in module 'C:\localcodeusingnuget\bin\Debug\name.of.dll'. The system cannot find the file specified.

The proget webpage says the symbols are available and gives the guid and the age which I can get a pdb with.

In this case, I would guess you are inclusing pdb files in your NuGet package?

As such, that won't work, because visual studio first looks for the local pdb (which it finds), and that pdb points to d:\blahblahblah, not to http://proget/. You may want to enable the "strip symbols" option to prevent this from happening.

http://inedo.com/support/kb/1036/using-progets-symbol-server

These instructions suggest that the symbols would be required to be indexed but the stripped when requested.

The nupkg downloaded by VS has no PDBs in it

using wireshark and procmon I can see VS download the pdb from the proget server, but then still gives that same message when stepping into code from that dll

This is unfortunately not trivial to debug, and will require understanding/learning how the symbol/source serving work (and the arcane tools to inspect said files), since it could be any number of things at this point, from your local pdb cache to improperly build pdb files.

But take a look at some of the other Q&A posts with symbols tag, specifically this one which shows how to use pdbstr.exe to inspect.

If you find out specifically what the issue was, please do share it.