I send out a lot of links to my articles in response to questions that come up, but the other day I had a chance to use a pile of them to solve a fairly complicated problem end to end. So, I figured I’d share how we can piece together all of this knowledge to solve a more sophisticated problem.
Let’s begin at the beginning. The CorrectFilePaths shim wasn’t working. We were trying to redirect c:somedata.txt to %userappdata%somedata.txt, but it wasn’t working. Why not? We weren’t sure.
So, we started out by turning on shim debug spew to see if the shim was being wired up. Indeed it was – we could see it picking up the shim when we launched the process. We could also look at the process in Process Monitor and see in the stack that the call to write c:somedata.txt was passing through AcLayers!NS_CorrectFilePaths::APIHook_CreateFileA. So, we knew that the shim wasn’t improperly applied.
Our next hypothesis, then, was that the shim’s command line was not configured properly. I tried copying and pasting from Process Monitor in case there was a copy error, but no such luck. So, it was time to go in with a debugger and see what was happening.
Now, where do we set the debugger breakpoint? Well, why not when we enter the shim? So, I set a bp on AcLayers!NS_CorrectFilePaths::APIHook_CreateFileA and took a look at the arguments we were passing to this function. What did I see?
Indeed, it never specified the C drive – just the root of whatever drive you happened to be running on. And, since CorrectFilePaths just uses a literal string match, the c: was causing the match to fail.
Replace that argument with somedata.txt;%userappdatasomedata.txt and everything worked fine!
So, using a bit of knowledge of Process Monitor, a bit of knowledge on the Debugging Tools for Windows, and knowledge from this blog, we could actually solve a real-world problem. And that’s what I like to see. Let me know if you are finding gaps that nobody is talking about yet, and we’ll see if we can get them filled here!