This may be obvious, but debugging is all about input / algorithm / output. If there's something wrong, it's one of the three. Work with the method of elimination. Sometimes it's easy, sometimes it's not.

I'll give you an example from my situation:

I wanted to play an old DOS game on my modern PC and so I used DosBox. I made an iso from the original CD, mounted it, referred to it in the game's mount settings and launched the game.

Then, after I had saved the game and I tried to load it again, the game would say: "Could not read/write savegame". And so I thought something was amuck with my mount settings and I started fiddling with those, but it only made it worse and it gave me more (cryptic) errors.
The next approach was to save a new game and load that one. Nope, same problem.
Finally I decided to follow a DosBox tutorial for the game and load the game again.. same problem. So I think hmm.. my algorithm is correct.. my output is wrong.. so then my input must be wrong. So I decided to save the game again with these new and correct settings and low and behold, it finally loaded.

One thing to note was that when it failed to load the savegame, it was because it had done a partial save because due to incorrect mount settings it couldn't figure out all the right config folders/files/paths and my savegame ended up being corrupt with 80% of the files having 0 Bytes, which was suspicious. That usually means a file became corrupt.

And then it hit me.. if the game says: "Could not read/write", that doesn't mean the same as "Could not access the file/folder". It could access it, it just couldn't parse it. And of course.. the 'write' part of the message indicates that it messed up in writing, causing it to misread. Sometimes you really have to think about it..

Anyway, input, algorithm, output. :)