Let's face it, not every InfoPath form you write is going to work right on the first time. If you are dealing with a Full Trust InfoPath task from at some point you may need to debug it. In my server in question today, it did not have InfoPath nor Visual Studio installed. However, it did have the Visual Studio Remote Debugging Monitor installed, so I decided to give it a shot.
Remote Debugging an InfoPath form is not much different that remote debugging anything else in SharePoint. You run the Visual Studio Remote Debugging Monitor on the remote server and use Visual Studio to attach to the w3wp process on the remote server. There are a couple of catches though. First, if you are running VSTA from InfoPath the first thing you will notice is that there is no Attach to Process menu item in the Debug menu. I am sure there is a way to get around it, but I just decided to close VSTA, open up Visual Studio 2005 (you have to use VS2005 since it is a .NET 2.0 project - although you may be able to upgrade it), and opened the .csproj file for the InfoPath project.
Opening the project with Visual Studio 2005 gives us the Attach to Process menu item. InfoPath code behinds don't generate PDB files by default. So, you will need to go into the project properties, Build tab, and select Debug. You then need to click on Advanced and set the Debug Info to Full. Build the project and you will have your PDB file. Now you need to copy the DLL and the PDB file to the SharePoint server. I have been copying these files into the feature folder of the workflow (i.e.: TEMPLATE\FEATURES\MyWorkflow). I have no idea if this is the correct way to deploy Fully Trusted forms, but I have yet to find any documentation on how to do it and I know this works.
Once you have done that you are ready to attach to the w3wp process. Don't forget you can use iisapp.vbs to determine the correct w3wp process to attach to. Set a breakpoint in your InfoPath code behind and then execute your InfoPath form or workflow. If all goes well, your breakpoint will be hit. If it doesn't get hit, make sure you attached to the right w3wp and make sure that the DLL and PDB on your local computer match what is on the server.
One thing to note is when you start deploying subsequent updates, the DLL for your form will become locked and you won't be able to deploy a new one. Be aware of that if deploying via solution package as it won't give you an error and it will just fail to copy things. Once you are done debugging, you will need to terminate the current w3wp process to release the lock and update your DLL. Also if you are just updating the code and not the form, it is ok to just copy the DLL and PDB out and not reinstall the feature and reattach the workflow. That should save you some time.