Do you have appropriate testing (including, but not only, unit tests) for the system? It seems like you don't, in which case I would start by adding enough tests to be sure that the application behaves as expected (since it fails to fulfill the requirements for the moment, if I understand well your question).
Then, documentation's purpose is to introduce the code to the new developer who doesn't know anything about the architecture of the existent codebase. It means that documentation is not really intended to find where a problem occurred.
When the piece of code behaves unexpectedly, you often start reading code, not the actual documentation, which can be obsolete, or just totally wrong or misleading. In practice, when systems I debugged had documentation, it was obsolete or wrong all the time (concerning the debugged point). No exceptions. Either the documentation was written from requirements and the error was introduced in the code, without reflecting the documentation, or the error was the consequence of slight changes at code level, while documentation stayed the same.
Following the comments, I see that I slightly misunderstood your question, which is more about "How I understand the existent codebase which has no documentation at all". It depends. In my case for example, generating class diagrams is something precious. This is the first thing I do before starting to work on someone else's code, and sometimes the only thing. But I also know people who don't bother generating those diagrams, because they find it totally unhelpful.