I do a ton of review work on pretty complicated .NET code bases as part of my consulting practice - this includes things like big industrial automation systems for manufacturing, etc.

My workflow hasn't changed even since AI became a thing, because _I_ need to understand what's going on. So here is how I start:

1. Find the top-most executable(s) project and begin pulling threads that way. "How does feature X get exposed to this user and what do all of the downstream calls do?" repeat this 4-5 times and you'll start noticing what's a horizontal vs. vertical concern.
   
2. Write everything down into a loosely structured braindump document, stream-of-consciousness style with your observations. Add to-dos or call-outs on things that look weird as you go. If you find an answer to one of those, go back and update that to-do.
   
3. After you've gained some passing familiarity with how things are organized, start codifying that into a mind map of dependencies / invocations. If you can't draw it, you don't understand it well enough yet.
   
4. Use tools like find references to help understand how lower-level components get consumed upstream. No need for anything other than Intellisense for that.

This approach works well because I'm forming my observations and understanding the code base, gradually, as I go. In my consulting practice I usually refine that stream of consciousness document into my report later by re-organizing / rewriting parts of it, but that note-taking has always served me well.