I actually think this is one of the best arguments for using apache and mod_php rather than fastcgi. It's hugely important when you have a performance crisis in progress. I've occasionally pondered looking into what it would take to implement that in php_fpm, but haven't found the time to do so.
Unfortunately my answer is linux based, which may not be helpful to you (given that you reference IIS). I'll put the answer anyway, and maybe there are windows equivalents to the tools I mention)
You could set up some ad-hoc capability by putting something right at the beginning of your php processing which logs the received URL, the process ID of the PHP process, and perhaps some other details like timing. You could also log the finish of processing, and that would be particularly important if you couldn't rely on the logging being done for all of the PHP requests.
I haven't found a good way to connect that URL and the front of the stack to the PHP process, but I have had success tracking from a Postgresql process back to the PHP process, by following the socket IDs in lsof. This is made easier by each postgresql session being handled by a separate process. I don't know how to do the same for mysql, but neither have I put much effort into that. Aside from tracking socket IDs, you can also make progress by looking for queries in the packet data, and then looking which processes hold the port IDs associated with the traffic that interests you.
Another approach (the most useful one I know on linux) is to look at what is going on inside the php process that is using all your CPU. Your primary tools here are strace and ltrace. Be aware that you will impose extra cpu and IO load in doing so, but you can attach a process to log the system calls (strace) or library function calls (ltrace) associated with the process you are interested in. It doesn't always work because you can have a process get stuck in a tight loop which doesn't call out to the system or other libraries, but more often than not this will get you what you need.
I haven't really gone into this, but I presume it's also possible if you use php-dev to attach something like gdb to your process which would halt, and you can look at the stack. you'd get a C language stack rather than a PHP stack, but presumably you could find the names of php functions in there and figure out which functions are involved. As I say, you'd have to pause execution, but if you scripted something to attach gdb, print out a stack listing, and disconnect, you wouldn't have to interrupt things very much. I suspect that there are windows debugging tools used by programmersin languages like C, C++ and maybe C# that can do this?
It'd be worth looking over what you can get from the various PHP debuggers.
So that's not exactly what you asked for, but perhaps you now have some ideas about other ways to attack your problem of figuring out what's happening in the active process.
Maybe someone else can point out some windows equivalents to the linux tools I use?