While there is a lot of advice on how to do a great many things in software, much of it requires understanding all the tools around you and the business logic involved - often to a very deep level. The problem here is that you may not be familiar with those tools and the business logic probably is not written down, let alone digestible.
Coping with these issues is often, glibly, described as getting experience with the tools and just reading the code as much as possible. This is not helpful. Firstly, it does not advise on how to approach a large system - where best to begin reading and what to do when what you're reading doesn't make sense - and how to cope with the deluge of information found when looking up toolsets being used on a large, often legacy, project.
I fully intend to expand on this post at some point with truly useful information, but for now I will link to some helpful, though not oracle-like, posts found around the internets. These probably state the obvious techniques you've already tried - I know I have. They also might incite you to keep going, as maintaining will power can be a challenge, too.
- How do you dive into large code bases?http://programmers.stackexchange.com/questions/6395/how-do-you-dive-into-large-code-bases
- What is the most effective way to add functionality to unfamiliar, structurally unsound code?http://programmers.stackexchange.com/questions/135311/what-is-the-most-effective-way-to-add-functionality-to-unfamiliar-structurally
- I've inherited 200K lines of spaghetti code — what now?http://programmers.stackexchange.com/questions/155488/ive-inherited-200k-lines-of-spaghetti-code-what-now
- Time Management Techniques (PluralSight video)