CodeLens References missing completely, despite being (forcibly) turned on

[emwl]

I'm not sure if this should be an issue already, or something we should talk about first; so I'll create a discussion for now.

Starting with the upgrade to 17.13.0, I've randomly experienced an issue with CodeLens...specifically, it doesn't show References at all. And I don't mean "- references" with a broken reference popup (as others reported numerous times), I mean "it is completely missing" (don't worry about the lack of data; the rest works, but I chose a rather neutral class that doesn't contain recent changes and potentially show people's names).

Despite the fact that C#/VB References are currently force-enabled due to a design difficulty from a while back (see #36378).

I can even violate the design decision that #36378 mentions by disabling the rest of the options, which leaves an empty margin between CodeLens-enabled members behind.

I have the suspicion that it might have something to do with loading/reading user settings, since I usually have at least two instances of Visual Studio open: One server application/solution (15 projects) and its associated fat client application/solution (14 projects); which I tend to open by clicking the solution file within seconds of each other. I normally wait until the first one is open and shows me my last opened files, but at that point there is no CodeLens visible just yet.

And so far, the only way to get rid of it is to wait longer (until VS shows CodeLens). Deleting the .vs folder was a placebo that I tried, and it has no effect on whether it is there or not; the only thing that does have an effect is time. And depending on which one I start first (or how quickly I do it), I can make either of them (or both) have no references.
Restarting VS magically fixes it.

Truth be told, it is annoying (to me), and I'd like to see it addressed; but I have no idea what kind of information I could possibly provide to help the investigation. What can I do here on my end (other than providing the solutions; which won't be an option)?
It feels a bit like it might've even been a pre-existing issue, and something in 17.13 made it more likely to occur? Since I didn't change a whole lot in my daily routine in starting up those solutions.

[jasonmalinowski]

Do you see this with only certain files or certain projects?

[emwl]

That's a very good question. I rarely have other solutions/projects open these days.
I just tried a few others (4 projects .NET Standard 2.0, 12 projects .NET Framework 4.8, 14 projects mixed .NET Framework 4.8 and C++/CLI), and didn't see it happen.

But then again, it also didn't happen with the two originally mentioned ones (also .NET Framework 4.8, since that might be a potential factor that I forgot to mention before). Might've intimidated the issue by posting about it, wouldn't be the first time.

As soon as I typed that, I realized something. My workflow starts a little earlier than that: By picking remote branches from my coworkers to review and test, checking them out (thru Git-bash running in Windows Terminal), potentially merging in multiple ones to give them a spin together and save some rebuild times; and only then start VS. Rinse and repeat for the second solution. Which means it needs to go reindex the source changes (and could be the reason why restarting VS fixes it). I didn't do that on my first attempts, which probably means I didn't hit the critical timing section that causes CodeLens to miss the References part.
In that sense, I'm a CLI guy, I prefer to switch branches etc. outside of VS (and, in fact, beginning my day I do so without even having VS open to begin with). And I also work on detached heads unless I work on changes myself (less stale branches to clean up afterwards).

Re-test with a 15 project and a 12 project solution: the 15 project one didn't have CodeLens References, despite being the first one to start.
So yes, I can somewhat reproduce this with different projects too, but less reliably. I'd argue those two are the biggest solutions I have floating around here; most of the time we split them up rather than combine them for build time and general separation of what goes where.

Wall-clock time, it takes about 7 seconds until the VS window shows up (from the splash to main window), 21 seconds until I see the document tabs, 29 seconds until I see the document content (it's just the tab with "Loading document contents" until then) and finally 54 seconds until CodeLens renders; then about 5-6 more seconds (total 1 minute-ish) to show the actual reference count. Both projects are about the same loading-time wise. According to our version control, it's a ~400 MB repository with 130 branches, 160 tags, and 35k commits (which is 5.5 GB on my disk, including artifacts; 20 MB .vs folder). Both on an NVME drive (same drive).
I'd say I'm usually in the 30 second to 1:30-ish minute window when I open the second solution; I often only wait until I see the main window come up (mostly because I had other settings issues back with VS2012 and VS2013, where I learned not to open two of them at the same time).

I also rebooted in the mean time, so I wouldn't be surprised that I had other stuff running in the background that affected the general machine performance (and make it easier, or like today, harder to reproduce). I'm currently on a rather old basically-EOL machine with an i7-6700 and 32 GB DDR4 RAM that is scheduled to be replaced with in the coming months; so maybe it'll go away on its own after that.

I've stumbled across %LOCALAPPDATA%\Microsoft\VisualStudio\SettingsLogs but didn't see anything useful or related in there. Everything else in either %APPDATA%\Microsoft Visual Studio, %APPDATA%\Microsoft\VisualStudio and %LOCALAPPDATA%\Microsoft\VisualStudio didn't seem too useful either (at least to my untrained eye, looking in from the outside).
Are there any log/trace files I should be watching out for?

[jasonmalinowski]

It's very strange this would be flaky, hence my questions. The fact the tagger is running (since other things are correctly being shown over members) but not that portion is odd.

What might just help here -- next time you see this, go Help > Send Feedback, and choose report a problem. That report will capture some logs for us to look at. Link to the created ticket here.

[emwl]

Done, created feedback item 10864159.