Do you mean tracking ccc.exe process only? If so, then 2.4 MB
http://zimage.com/~ant/temp/ProcMon3.61cccEXE.7z (too much information
for me -- yikes).
Impressively complicated for such a small trace file.
It's to be expected, that it looks like a slow motion train wreck.
I can see a "presentation" file from .NET, reading the
font registry entry. There is no sign of anything "wobbling"
at that instant. The framework at that moment, hasn't
started to evaluate the path info or for that matter
the font file types. If it parses the path and barfs
part way through (without attempting to open any files),
procmon won't have a record of that. This is not GDB, it
doesn't record instruction execution.
One thing that's weird, is CCC.exe itself goes looking for
fonts on its own, like segoe ui font and some other stuff.
It doesn't look like WPF does all the fonts for the control
So far, I haven't managed to find a "smoking gun" trace entry
where something fails. There's quite a lot of threading.
Right up until the end, CCC is reading registry entries,
there is DLL after DLL being loaded, and so on. You
don't really see anything "stumble" over a period
of 15 or 20 seconds or so.
The only real puzzler (a comprehension problem on my part),
is I spotted an entry on the stack that has no metadata.
I *hate* when Windows does this. I've seen a few weird ones
like this before. Like, I've had processes in Task Manager,
missing metadata and still running. The operating system
should *shoot dead* **** like this! No metadata - no cycles.
That should be the policy.
Why is excrement like this allowed to run ?
Is it malware ?
What is it ?
It's unlikely the stack will unwind enough to hit that,
but it still lacks precision and should be put out of
its misery. This is a computer, it's not a slumber party.
Well, now I don't know what to do next. Some code is
failing, but I'm not seeing a splatter. It looks like the
eventvwr this time, provides more info than tracing does.