In general, yes, code review is a good way to learn a code base.
As described, maybe, code review is a way to learn VC++.
I know that's wishy-washy, but it truly depends on the goal of the code review and how it's carried out. If you're being used as a QA step, independently doing code review at your work station to distract you while your dev system is set up, then you're going to have a hard time learning anything. You can certainly turn it into a learning experience with the right mindset (taking notes, recording questions), but it's an overwhelming way to start. You have no context, and in this environment, no way to even test your assumptions. This is not dissimilar to the age-old trope of putting new team members on low priority bug fixes. You'll learn enough out of necessity to fix that bug, but you won't have the big picture.
If the goal of the code review is to get you familiar with the system, then it should be carried out as part of a group exercise, with projectors and discussion. A code review is a great way to focus communication and the instant feedback you can get can accelerate your learning curve. You'll have an opportunity to point out confusing parts and get answers in context of the code you'll be working on.
Given your constraints, I have two more suggestions. If you can setup a machine that will run VC++ (but not necessarily your project's full dev environment), you could try prototyping concepts as you come across them in the code. So, discover a new technology in your code reading, fire up Visual Studio, find an example online and get it running, then adapt the example (as much as possible) to match the code you're reading.
The other suggestion is to approach it as described in this other answer. This is a new system, you don't know anything about it and are encouraged not to trouble others. You can still do some measure of "debugging" via breakpoints, you just have to do it on paper. This will feel painful (it is), but it will improve your code reading skills and will give you another tool to use when firing up a debugger isn't optimal.