#1 Burning Software

Use SPTD to bypass broken filters they install. That's what SPTD was designed for.

Well...I am not going to use SPTD by default, since I don't want to add further dependencies unless necessary. I still don't trust SPTD, it can (and did in the past) also add issues instead of solving them.

So: If you say that with VirtualDrive Pro installed, StarBurn simply cannot be used in SPTI mode, that is fine with me and I can always tell the user to use SPTD instead, *but* my application needs a way to figure out that something is wrong. Hanging is not good. So is it possible that StarBurn, instead of not responding, can emit an exception? Or is it reasonable for my app to have a timeout for this property access?

No it's not what I say. It could be something inside StarBurn so it's a good idea to try STPD and if your user would continue having the same issue we'll be happy to take a look. Ether locally or with remote session.

If I'd write a filter driver just spinning some command forever would you suggest another app developer whose command we're spinning "fix" their application? How? And that's basically what you're suggesting us to do... SPTI is unreliable way to access hardware and that's why no serious commercial app uses it entirely. You may use it or not but telling us we need to "fix SPTI either way" is a little bit confusing.

1) I cannot guarantee it's StarBurn or VDP issue. If it's StarBurn issue (the same things happen with "safe" SPTD layer) we'll fix it. It's not StarBurn issue - we cannot fix it. Right now SPTD is only the way to check.

2) We cannot workaround every broken software. We'll have a MESS inside our code. That's what SPTD is going to help with. Bypassing broken filters.

Excellent! Could you please ship both versions (STPI Vs. SPTD) logs initially and we'll try to find out what we could do here.

There you are.

According to the log StarBurn does not hang. It's just trying to get virtual device properties and emulator completes command with I/O device error (Windows code 1117). So we're trying again and again as this command is not supposed to fail until it does not reach maximum limit (5000 iterations). Unfortunately there's no way to turn off this is control number of retries (we don't have such an API as these values are hardcoded) so we'll take a closer look later - I think we can fix this some way.

Great, thanks. 5000 tries might indeed not "hang forever", but long enough to assume the application needs to be closed using the task manager.