While at a Breakpoint or Stepping, I Find that FusionDebug Loses Its Connection to the Request
There can be a few explanations for this problem. First, if your CFML page experiences an error, then CFMX will return an error page to the browsing user but will no longer provide the debugging information that FD requires. As such, FusionDebug will just stop debugging that request with no indication of the error having occurred.

IMPLICATION OF REQUEST TIMEOUT SETTING
Another common problem, especially in CFMX 7 (though it can happen in 6.1 as well), is that while you are stepping through the code, ColdFusion could time out the request. Many know that the CFMX admin console permits specifying a value labeled "timeout requests after x seconds." This protects the server from excessively long-running requests.

Unfortunately, FusionDebug holding a page during stepping will appear to the server to be a long-running request. If CFMX terminates the request, this will cause FD to lose the connection to the request without any indication.

While CFMX 6.1 has this option, it's disabled by default in the new CFMX installation, while in CFMX 7 it's enabled by default. You can override the page request timeout on a page basis using CFSETTING RequestTimeOut.

Implication of Holding Breakpoint Across CFLOCK and CFTRANSACTION
Although this won't necessarily cause a problem for you, something to be careful of when holding a breakpoint is running code inside a CFLOCK or CFTRANSACTION. Either could negatively impact other threads or users. In the case of CFLOCK, you could hold a lock that could hold up others trying to get the same lock. (Locks are a subject of frequent confusion, but further discussion is beyond the scope of this article.) In the case of CFTRANSACTION, you could hold a lock that holds up others trying to access the database you're processing since CFTRANSACTION (driven by its ISOLATION attribute) can tell the database to prevent other reads or writes during the life of the transaction.

Traps: Challenges on Shared Servers
If you do choose to enable FusionDebug on a shared server, such as a central development, staging, or perhaps even production server (in an emergency), be aware of the following potential traps.

Breakpoints Remain Alive for Any User (Not Just the Debugging Developer) While Debugging Is Active
As discussed above, if a user runs the request while debugging is enabled, the page will appear to hang to the user. Only the developer with FusionDebug open will see that it's stopped on the given breakpoint. For now, there isn't any option in FusionDebug to limit the IP addresses whose requests trigger breakpoints.

When multiple users make a request for a page while it's being debugged and hit a breakpoint, FusionDebug will show a "thread" for each user's request in the "stack trace" pane. If this happens and you want to quickly stop the debugging, you can choose to use the "disconnect" (not "terminate") icon in the stack trace pane. That will stop all debugging in the current debugging session.

On the other hand, another approach would be to use the available "skip all breakpoints" option (in the breakpoints pane) to temporarily disable breakpoints from firing any further for the current debugging user.

Who Can Debug Your Server?
For now, there isn't any option in FusionDebug to limit which IP addresses can initiate debugging. Since debugging is enabled simply by specifying a given port, any user who can issue a request against that server and port (and is running FusionDebug) can conceivably set breakpoints. Of course, they also have to be able to open the file via an Eclipse project to set a breakpoint, so effective file security and firewalls can mitigate this concern. 

What Happens When Two or More Developers Try to Debug a Single Shared Server?
Because of limitations in Java and its debugging mechanism (which FusionDebug is leveraging on our behalf), you can't have more than one debugging session open against a given server at a time. If a developer attempts to start a debugging session when another developer has already started one, the request will be denied. Again, in such cases, this calls for judiciously controlling debugging sessions using the "disconnect" feature to stop debugging when no longer needed.

ColdFusion Doesn't Start After I Configure It for FusionDebug
It could be either of two problems. The simplest is if you've made a mistake in configuring the jvm.config file (Jeff explains what to do in the installation steps). If this file has errors then CFMX won't start. So it would be wise to save a copy before editing it, but if it's too late, just read the installation instructions carefully (or contact FD support).

A second reason can easily occur for those using CFMX Enterprise and its available multiple instance deployment option, where you have multiple CFMX instances on a single box. In this case, if you configure just one jvm.config that's shared among them all, there will be problems. See the support FAQ at www.fusion-reactor.com/fusiondebug/support.html#config2.

Conclusion
Well, that's a pretty deep plunge into tips, tricks, and traps. I hope they're useful for you. I've spent nearly half the article on gotchas, but to be honest, many of them can be avoided if you simply read the documentation. But I realize many people won't bother so I've highlighted them to help make you more effective in considering using the tool and getting started with it.

Share your experiences with colleagues but be sure to take any negative ones to the vendor. I've found them to be very responsive.

I really think it makes a great tool for the CFML developer's arsenal. And there's great support behind it - Intergral is no start-up; it's several years old. They're CFML developers committed to making tools and add-ons for CFML developers. Check out the free trial, as well as community and volume discounts.