XACT_E_CONNECTION_DOWN following SQL Server restart

Environment: Win32 services dependent on a local SQL Server 2008 R2 service. No database mirroring, no remote resources. Several of the Win32 services have startup logic that involves calls to a COM+ service (transactions required) which accesses databases on the SQL Server (using msado15.dll, MDAC 2.8). During a normal system boot-up sequence, everything works perfectly.

Scenario: Manually restart only SQL Server. Because of the service dependencies, this restarts those additional Win32 services. Non-deterministically (in ~30% of SQL Server restarts), a call to _ConnectionPtr.Open fails with HRESULT 0x8004d01c, which is XACT_E_CONNECTION_DOWN, message "Connection failure"; if the whole COM+ call is retried a few times, it eventually starts succeeding reliably. With most SQL Server restarts everything just works fine every time, same as with every full system boot-up.

What could cause this? How do I debug DTC? How can I get some insight into what's technically the root cause behind XACT_E_CONNECTION_DOWN? If I want to reproduce without any COM+ transactioning involved (so as to simplify the scenario), how do I enlist an ordinary database connection into a distributed transaction?

What else we tried:

• The same problem may appear (with a similar probability) even if the SQL Server service is made dependent on the MSDTC service and the MSDTC service is restarted, along with all its dependences.
• Remember that this can be independently observed in more than one service. If the problem appears in a service with a retry loop (retrying the whole COM+ call), and eventually fixes itself, another service still can transiently have the same problem during its own startup, even if this was provoked by the same SQL Server startup. Therefore it can't be as simple as SQL Server not being ready to talk to DTC before some point.
• Nothing unusual in Windows Event Logs, SQL Server logs, nor MSDTC logs. The distributed transaction appears to have been aborted by the beginner.

Edit: - We found no MSDTC settings that would not reproduce the problem.