v7 drivers (64bit)

[DragonSF]

No problem, next step will be the deep inspection of the call DeviceIoControl as isolated culprit. I need to gather all the parameters with disassembly ( a little bit on the tedious side ), but I hope, I come to a conclusion soon. After that, it's up to the party, who's in control of the driver. I'm not (and don't want to be) in a position, to speculate, how certain software providers do their job (i.e. how theyt got ASIO working for their products under Win10 64-bit). But I'm confident, that I either find the correct way or a proof, that there is no way ATM.

[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.

[DragonSF]

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.

Did I complain? If so, not intended at all. I just want to keep my favorite apps running.

[valis]

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

[DragonSF]

2 results from today:
1. ableton libe 64-bit is working (with windows 7 compatibility mode set). And no, etting this mode to my test program doesn't help.
2. the dll uses a function call which is supposed not to work under Windows 10. Why is works with 32-bit, escapes me.

[DragonSF]

More strange results
- running my simulator (using only the essential parts of the ASIO driver) in X86 mode works fine (i.e. I have the correct paramters for device control).
- running the simulator in X64 mode survives the system call, but generates an exception (access violation).

[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?

[DragonSF]

" 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?

Win 10. I have to try compatibility mode. ATM Win 7 doesn't work anymore (no idea why, I can't login).
Tried, same error. But this error has IMHO nothing to do with Scope.
The exception was due to the fact, that I declared some of the variables involved as int, where DWORD was the correct type. No idea, if this is the same in the original source code. So far, I can't reproduce the BSOD with the simulation.
If someone else has ideas, I could try, I'll do my best. But so far, I'm confused a have to stop here. Unless I can try with the original code, my hands are bound. Sad enough

[DragonSF]

Got my Win 7 working again. Tested in both x86 and x64 mode. As expected, nothing weird happened. In x64 the final syscall is #4 (status of the device) which returned the correct value.

[DragonSF]

Good News: I got the source from Holger and now I can find found, what's really happening.

[garyb]

great!

[next to nothing]

Nice, keeping my fingers crossed

[DragonSF]

First findings: (as expected) Ableton Live survives the same syscall, which ASIO SDK host doesn't. I.e. I can reproduce the problem, but still have no idea, how to fix it. I have to dig deaper into that specific call (it's actually not the first call which creates the BSOD, but other call have different parameters). The call itself is trying to get channel info (harmless enough).

[DragonSF]

After some in depths debug session, my conclusion is (sad as it might be):
there is nothing wrong with the ASIO driver. The problem occurs deep in the scopexite.sys driver and is an access violation exception at this code:
mov dword ptr [rax+rcx*4],0FFFFFFFFh
with rax=00000000ee97f8b0 and rcx=0000000000000000.
The rax address looks suspicious, because the memory context is fffff08efde8aae0. IMHO rax should be ffff08efee97f8b0 (which is within kernel memory). But I'm at a loss here, I don't know anything about system drivers.

[DragonSF]

My suspicion was confirmed: ASIOScope uses 32-bit Address pointers when it should use 64-bit pointers. As Ableton runs in 32-bit memory space, there is no issue in that case. I informed Holger about my findings and I hope I could help. I can't do anything further atm, because not only the ASIOScope dll has to be changed, but also the scopexite.sys driver.

[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?

[DragonSF]

I asked me myself the same question. I'll take a look at that later. Maybe in Win 7 all process are running in 32-bit space.
And Voicemeeter is working, because it's a 32-bit application.

[DragonSF]

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