So I think your 'test situation' is just too complicated, turn some stuff off !
So another thing worth mentioning (both for Ron & anyone who passes by also confus-ed by this) is that as far as windows is concernced All cdrw writing is done via scsi - oh no it ain't I hear you all cry, I've only got IDE or something else that ain't scsi, anyway nothing that is, so how can they all be 'scsi' writes ? ...
Well every single writing application there is ennumerates a scsi device for any atapi type writing, they all introduce a proprietry driver to ennumerate the scsi bus & take advantage of the direct functions of that interface, try starting any machine in safe mode & you'll find a 'non windows driver' {it says press 'esc' to avoid loading} hanging about, these 'drivers' though can be a nightmare .. (strictly they aren't really drivers, as they ennumerate a device class to take advantage of that classes features)..
Methinks this will get more solveable if we figure out whether ANY writing s/w is at fault or not - so I think that's relatively easy to figure out, take all your writing software off for now (also check via my 'safe mode trick' that we still haven't got some non-windows driver hanging about) & then see if we get all these reconnect issues ..
BTW all these other TSRs mentioned 'not loading' at various points can't be helping either, for troubleshooting purposes, the less running at any time the better .. RUNDLL32 simply runs a dll as a seperate process (makes it like an .exe or near enough) its never a very reliable way to fire anything due to how encapsulation works in an embedded programming environment (can't get released program hooks as not 'parent' process - leads to lots & lots of 'timing' issues !)..
& I just realised you've got INCD running all the time - this is packet writing s/w (makes a cdr type device 'behave' as a hard disk) - for now lets also be rid of this complication, first we want to know if the 'reconnecting bit' is getting done right, never mind buring s/w going 'screwey'..