views:

22

answers:

2

I'm dealing with some hundreds of thousands of lines of code, and I'm stumped where this process is accessing a particular file. I've given up searching the code, I just cannot find out.

So, here I am -- asking a question I'm almost certain there is no simple solution for.

I've tried FileMon, ProcMon from SysInternals, and while I can see the file got accessed, it doesn't show the call stack or any useful piece of information.

I wish I could break into the debugger when that happens; I thought maybe I could write some extension for FileMon that would signal to me when an access happens, and then I could throw a Debug.Break into my process.

Any insight or ideas appreciated.

A: 

Set a breakpoint on CreateFile(). Write one in main() so you can easily trace into it an find the API entrypoint. Switch to disassembly view before single-stepping.

Hans Passant
I tried that -- it's time consuming, I have over 300,000 calls to it. But I guess it's the only way. I'm wondering if maybe the C# code maybe accessing it, will that go through createFile as well?
mjsabby
Good lord, no wonder you can't find it. Yes, *all* file access need to go through CreateFile. Your next option is patching it so you can write code to compare the file name. Use Detours: http://research.microsoft.com/en-us/projects/detours/
Hans Passant
A: 

Is the file created by the program or is it pre-existing? What would happen if you renamed the file on disk, maybe that could help you get a stack trace? If it's generated by the program does the file name adhere to a specific pattern, maybe you could look for the format string that populates this pattern, e.g. "c:\%d-%d-%d.txt", and then look for the lines that use this string.

James