v7 drivers (64bit)

[jksuperstar]

Any remnants of old 32bit drivers that are getting picked up?

[valis]

This may be why setting the application (not Scope) to Win8.1 (or Win7) compatibility mode is of some help to hosts who otherwise crash... it might give NtDeviceIoControlFile the 0x0004 response... (or at least not 0x0007?) That's assuming of course that this is the difference that does indeed cause hosts to not work with Scope 64bit drivers...

[garyb]

again, my ignorance will show, but this looks like what i would expect. if the app attempts to set up the hardware, it will crash, because the Scope hardware is not supposed to work that way. it is lousy programming to assume that all sound interfaces will be windows soundcards.

[garyb]

..so, then the fact that STEINBERG apps work with Scope ASIO means nothing, since Port Audio obviously has it right...

[garyb]

got you.
now i understand what is happening.
i was obviously confused.

carry on...

[valis]

If you can provide detailed information it will surely assist the development of the driver. The real question is time, as in the developer(s) have a finite amount of time/resources and so who can know when things can be addressed. It's surely better to assist as much as you can instead of just complaining though.

[valis]

You did not, I was indicating that you were being helpful.

[next to nothing]

" running the simulator in X64 mode survives the system call, but generates an exception (access violation)"
I guess that is in Win 10? or do you get the same access violation in win 7 64bit, or running your simulator in compability mode?

[garyb]

great!

[next to nothing]

Nice, keeping my fingers crossed

[garyb]

that's good work.
i'm sure if that's the problem, that the fix will come much sooner that it would otherwise.
i'm sure Holger appreciates your effort.

[w_ellis]

Amazing efforts here! I'm super impressed by a) the dedication to get to an answer and b) the tech sleuthing. Fingers crossed it leads to an even more stable Scope.

P.S. I have been able to BSOD using the Juce VST Demo Host using ASIO in the past, which was probably my bad code, but could have been related to this.

[next to nothing]

w_ellis, the Juce crash was probably driver related. This case has some similarities to this thread: https://forum.juce.com/t/asio-devices-c ... t/18795/15 as far as i can decrypt it

Good work DragonSF. This could explain a lot, but one thing is nagging me; the different behaviour in win 7x64 / win 10x64. Does 7 "accept" 32bit pointers, but not 10?

[t_tangent]

Fantastic work there DragonSF, and of real value. Im not a programmer but I found this thread fascinating following your detective work, and I am sure your findings will be most appreciated by the devs and us all here

[next to nothing]

Just to confirm: under Windows 7, the ASIO driver is loaded into 32-bit space. Therefore no problem.

If this is the issue, it shouldn't be too much of a hassle for SC to fix as far as i can see, which is great. Pedantic me would probably say it's a strange oversight to let this pass on a release focusing on win 10 compatibility, but at least they now have something to focus on.

Again, great work Dragon.

[next to nothing]

Good News, Ableton live 10 x64 still works in compatibility mode

[asiofixer]

hello
i don't understand much windows and midi protocol drivers but i have install scope 5.0 in win 7 x64 and i have no problem with samplitude
even cubase or sonar not working as good as samplitude
i also use protools hd for plugins in rtas mode
i have no more latency audio or midi