There are two things going on here.
First, these file name/path references are referring to CFML code in files that have been precompiled--a feature used relatively infrequently by users, but used often in CFML code distributed by Adobe. Most CF Admin CFML pages are precompiled, but that's not likely what you're hitting. Instead, a surprise for many is that several CFML "tags" are really deployed under the covers as CFML files (see \wwwroot\WEB-INF\cftags).
And if you ever have either an error in such files or somehow end up in them in the debugger, you will see this reference to the e: drive, but it represents the actual path where the source existed on the machine of the developer who "built" CF (before it was distributed per the installer to you).
As for how you could end up inside them in the debugger, well, again, some CFML tags are deployed as CFML files, so for instance if you "step into" a CFDUMP tag then I could see this happening. I'd hope that Adobe would detect and prevent that, but I can't recall if they do (and don't want to fire up a demo at the moment to confirm).
But let us know if any of this helps.
Providing CF and CFBuilder troubleshooting services
Charlie...thanks for the explanation. This helps to alleviate my concern that I had set some process or vector in motion that unwittingly made these "e:\..." references appear in the debugging process. Your explanation makes a lot of sense and is all I needed. As for the developers...well, this bit of sloppiness only caused me a minor amount of trouble...