Xperf error: Cannot create a file when that file already exists

I've gotten a lot of highly negative feedback based on my last post and rightfully so. I did not explain myself very well as I was trying to make a brief example and not go too far into it because I was answering too many things at once. I plan on responding to this in full tomorrow. As just a short post however I wanted to address this particular issue: a conflict between Xperf, Resource Monitor and SpiderOak.

In my current pet project I have a requirement with a memory ceiling (as I want it to consume less memory then alternatives I've tried and I yes I know virtual memory/paging makes image size not a big problem but I have my reasons), and I am experimenting with both Windows and Linux. Linux has some great memory profiling tools including Google's Performance Tools which wraps up tcmalloc up in a nice and pretty package. Regardless on Windows there are a few tools from Microsoft that really let you analyze the system as a whole so it's easier to separate your actual program data from just other things going on in your system. These Windows Performance Analytics(WPA) tools are available at MSDN.

The problem I was having was that every time I was trying to start Xperf (the main tool in WPA) I was receiving this error:

C:\>xperf -on DiagEasy
xperf: error: NT Kernel Logger: Cannot create a file when that file already exists. (0xb7).

After looking around the internet to get more information regarding it I came across this message board post which linked up Vista/7's Resource Monitor with blocking the same interface as Xperf. When I started Resource Monitor however and attempted to start a trace it gave me the same sort of error: Someone else is using the interface. Fortunately though it gave me the option to override the access the other program had so it could do its job, but I wasn't able to diagnose what process it was.

Then as I started thinking and set about examining what processes would be using the same interface that resource monitor used? Then I realized that perhaps it was something monitoring the filesystem that got stuck? I hadn't rebooted my computer in a while so I took an accounting of all the long running processes that might be interfering. Of the two left I had SpiderOak and Procrastitracker. I tried killing Procrastitracker, but that didn't seem to clear up the issue, but I noticed that SpiderOak's icon had vanished from the status area. I booted up procmon and killed it's process tree including the utility it uses called 'windows_dir_watcher.exe.' After that was killed I was able to run Xperf normally.

Now I am not entirely sure it was SpiderOak because I can't figure out if I had somehow caught it in a crash state, but when you are trying to use Xperf you should spend a lot of time trying to explore what utilities might be using the same interface when you are getting that 0xb7 xperf error. Windows doesn't have a good equivalent to inotify, so maybe more tools are going to explore this interface especially with Vista/7 and soon 8 becoming much more ubiquitous.