Well I guess that reply was directed a both of us. I hadn't tried this solution anyway because it still doesn't address the issue. i.e. if a physical disconnect occurs while the VISA session is open. The text in the help about only keeping it open until you are finished is somewhat ambiguous. As far as I'm concerned I'm not finished with it until the user closes the application.
Sorry, I just realized that I had not actually addressed your issue. (Although, the warning against implementing Jorge's fix was important)
That FTDI chipset can be troublesome to work with. Worse, you stated that you are using a custom driver rather than the publically availably version! Going WAY OUT on a limb here- I would suggest speaking to FTDI technical support. The problem is likely resolvable but without the hardware, or software and not having access to the driver itself we can only "Shoot from the hip" and guess.
When I started working out on this project it seemed like the only way around that "Port Disconnect while Session was open" problem was not to wire the error input. Perhaps it was something else that I did not see.
However, I do agree that sacrificing debugging capabilities is not a great idea, even on a small SubVI which is only used when the application closes (in my case).
The problem is that I only have an issue with LV, C# works fine, so FTDI support are likely to send me back to NI/LV anyway. The driver as far as I know is based on FTDI's anyway and while it's "custom" it is Infineon's DAS driver. www.infineon.com/das.
I will try to replicate it with other non FTDI devices if I can find one and post a simple example here.
No C# uses the windows API, which is why I think it's a VISA bug/feature.
I'm just trying with a Prolific device and resuls seem to be almost even worse than with the FTDI! Just had a blue screen with that one!