PlanetZ forums - scopeusers.com

Hi There,
I have been experiencing BSOD's when loading Q-WAVE (Win 7 pro 64bit Scope 5.1, XITE-!).
I think I have solved it but would appreciate anyone's input.
I downloaded Q-Wave and 'merged' all the folders into SCOPE.
I then downloaded the Zarg64Bit folder and copied those files into the app/sys directory.
Q-wave worked until I changed a setting or loaded a new pre-set and bang BSOD!
Eventually I went back and removed the original non-64bit files from the sys directory that had loaded with the first install of Q-Wave, leaving the 64bit files in place, of course.
So far no BSOD's.
This all seems pretty logical, but it wasn't immediately obvious when I first set things up.
I hope the 64bit files are a direct replacement for the others and I haven't missed anything?
regards
maus

Life can be a shit sandwich!
As fast as I posted the above I went back to testing and BSOD!!!!!
Occurred when I tried to load a new pre-set into Instrument 1.
Not sure where to go next?
maus

i'm not sure either.

blue screens are rarely software induced. there's no problem with Qwave bluescreens here in any os.
i have heard of one other user who mentioned bluescreens, perhaps it was you?

@gary
I did mention it over in the 'Scope General Discussion' area, but someone else did as well.
I think you are right, regarding BSODs not related to the software par se, in that I have now had one with Solaris.

I am wondering whether we could start a thread where we can list Zarg Synth pre-sets that are 'light' (Non DSP overruns, etc.) and work with XITE?
These could be the starting points for us to develop usable pre-sets of our own, hopefully avoiding BSODs, DSP overruns, etc.
Just a thought.

Anyone who has experience with these synths on XITE and can advise on the best DSP setting would also be helpful.
I have tried playing with DSP as per someone's post in the 'Scope General Discussion' area.
Hasn't help as yet - early days - still testing.
regards
maus

the Solaris and QWave don't work optimally in the XITE, but they don't generally cause blue screens either.

Hey Gary,
I did a bit of research into BSODs and of course you are right in the they are mostly caused by hardware or low level software.
I note from the minidumps created during the BSODs that JBxxxx64.sys files are listed as drivers.
Also what is a little odd is the listed cause varies from 'IRQL_Not_Less_or_equal' to 'Memory_Management' to 'Page _Fault_In_Nonpaged_Area'?
The ntosknl.exe is blamed for the crash, but I suspect that is not the underlying driver issue.
Any technocrats out there that can assist here?
regards
maus

well, that would seem to be a memory issue. the first thing i would do is go to one stick of memory and see if the problem persists. if it persists, swap it out. this will quickly tell you if the ram hardware is the problem.

it's clear that the sys files mentioned are involved. they are scripts that involve the use of system resources like ram, and indeed it's a memory error. what's not clear is the actual reason for the errors...

Me too!
Two blue screens with Zarg Ambient will try the one stick of ram approach. But I thinks it's strange that I never got the BSOD until I used Zarg Ambient ?

there may be a bad sector that isn't being used by other processes. most current computers have a lot more ram than the programs actually use.


it might be John's synths, but i'd expect it to be a problem for everyone if it was. of course, all these machines are runnoing Scope "as administrator", right?

Yes running as Admin.
Got a 0x00000005 Error which is usually caused by driver or hardware install ! I installed a firewire audio card today ! Will remove and see if that's it

and though i know we've heard it ad-infinitum, that's Scope as administrator, not your windows user account right? you answered yes at the warning message asking if it's ok to allow Scope to make changes to the system? i know planetz knows all about this, but it's good to eliminate the obvious right away...

Not to sure! How can I verify that ? Edit found it will check in the morning it's time for beer!

right click on the Scope icon, choose "run as administrator". answer "yes" when asked if it's ok to allow Scope to make changes to the system. this needs to be done every time.

a few less clicks, right click on the Scope icon, choose "properties". on the "shortcut" tab, click "advanced". put a check in the box for "run as administrator". click "ok" or "apply". from then on, when you left click on the Scope icon, you will get the wanrning asking if Scope can make changes, and every time you must answer "yes".

this is all part of windows security. all kinds of crazy things can happen without admin access for the program, although usually you'll just get a "can't find dsp file vxd blah, blah".

o apologize if this is old news, i'm just posting it for whatever help it might be.

you might check for shared irqs as well. it's possible that the firewire device might be the real cause of the panic in ShogunSpy's machine if it's on the same irq as the Scope card.

I am running SCOPE in administrator mode. so its not that, but IRQ's may be an issue.
I have a M-Audio ProjectMix IO that connects via fire wire.
I'll check my interrupt sharing.
Regards
maus

FYI, last night I experienced some blue screens when using zarg Synths on a Win7 32-bit PC with two PCI Scope cards in. I haven't added any hardware devices. I started to go down the same route of checking its IRQ sharing too.

It did appear to only happen (twice) when selecting presets on the larger Zarg synths. When the computer crashed, what sounds like a partially-loaded synth sound would be coming from Scope, until I shut the PC off.
So I am guessing its when there is a lot of data being transferred from disk to memory to scope card where some delicate synchronizing is failing.
This would possibly tally with neuromantik's post on http://forums.planetz.com/viewtopic.php ... 9&start=40
"...where the synchronous IO being "bottlenecked"..."
What I don't really get is why there are JB-specific sys device drivers bundled with their devices. Suggests that some services that Scope provides are being worked around by device-specific workarounds. Generally, I'd be interested in why they needed to take this approach. So saying, neuromantik's post suggests that it's Xite's backward compatibility with PCI Cards is the issue here... I will think a bit more about this! But there's not much I can probably do about it...!

Since it appears that the devices appear to emit audio while changing partially-loaded presets, maybe because some envelopes from the previous prets haven't yet closed, I was thinking of sending an all-notes-off message to Scope before changing presets, or try setting the number of voices for the synth to zero before doing the preset change. Not sure if disconnecting the device's midi in and audio out would be sufficient, doubt it...
Since it appears that it's not easily-reproducible, then it must be that when Scope is in some specific state that causes the issue.

When diagnosing the IRQ Shares, I found that three USB controllers share IRQ with scope cards.
One of the usb controllers had nothing connected. Two had, one was my Creamware Noah which wasn't switched on, other was was Ableton Push.

To see what usb devices are plugged into usb controllers that share IRQ with Scope:

1. Find the IRQ Shares:
- Start the System Information program by typing msinfo32 into the Run box or from a Command Prompt
- Expand Hardware Resource, click IRQs, make the Device column wider by dragging the column header
- Find you Scope card's IRQ(s)
- Take a note of what other devices share that IRQ
- For USB controllers that share the IRQ, notice the hex number at the end of the device (mine are 3A3x)

2. Find what USB devices are connected to those USB ports:
- Start the Device Manager control panel, by going thru the Control Panels, or typing mmc devmgmt.msc from a command prompt
- In the View menu, click Devices By Connection
- Expand the ACPI Computer node, expand Microsoft ACPI-Compliant System, then expand PCI Bus
- Find those USB Host Controller nodes whose IDs (3A3x in my case) match those same devices that are shared with Scope
- You'll see there what USB devices are connected to the USB Port, by expanding the USB Host Controller node
- To free up that IRQ shared with Scope, you'll need to disable those Host Controllers. If there are devices that are on that USB Controller that you need, then you'll need to re-jig your connected USB Devices.
- Once you are happy that these USB Host Controllers aren't servicing any devices, you can right-click on the Host Controller node in the Device Manager, and select Disable.
- Restart your machine.

You can't do much damage by disabling USB Host Controllers. Worse-case, you disable the host controller that is serving your Mouse and/or Keyboard. Be prepared to plug your Mouse or Keyboard into an active USB port if you do that. And naturally, don't disable every USB Host Controller! That would be just a little bit silly... Please don't be silly!

I disabled the usb controller devices in the Device Manager. I didn't have the option of disabling those USB devices thru the bios, since the shared irqs are spread across the three onboard USB hardware devices (which is a pity, as that would have been a nice easy solution).

I've attached a screenshot of the System Information and the Device Manager that I took half-way thru the process, after having disabled the USB Host Controller that already had nothing connected.
I've also attached a screenshot of BlueScreenView - on my 32-bit system, it's Scope.sys is the cause of the issue.

To be honest, it was so late by then, I just used scope for a little, and then headed to bed! Not in a position to use the scope machine much today, not til later anyway..

Hope this helps (both me and others!). I'll test with my changes later tonight.

Yes Eanna I was also changing presets !

there may be presets that will make the system crash.
those presets were made quite some time ago, it's possible that there are some operations that windows doesn't like.

shared irqs with firewire or usb will definitely add to the mayhem. the card cannot share an irq with either and work reliably.

I agree Gary, sharing IRQ's is part of the ACPI specs, where the OS takes charge of IRQ assignments, such that it can override even what the BIOS indicates.

But, respectfully, device drivers that do not implement ACPI specs correctly, those that advertise as being Compliant with those PCI Specs, must ensure that they are programmed in such a way that
- They can share IRQ's with other devices
- Are not so fragile that they can result in BSODs

I also fully and totally recognise and appreciate that the nature of Scope, as a near-real-time system where glitching is easily measure by ear, does a superb job of fitting in well with a Windows-based OS, which was never designed to be real-time, and with ACPI, which has many high-level detractors.
I'm also mindful that I'm on a stock Dell PC! Albeit a modern one. And therein lies some further cost-cutting stuff at the motherboard level!

It's evident here that Scope drivers are at fault. And at a time when IRQ assignment was at the behest of the owner of the PC, it was OK to expect users to arrange their systems such that Scope had it's own IRQs. But nowadays, these drivers need to be doubly careful that they can live with a medium level of IRQ sharing.

Disabling ACPI, going back to the bad ole days of manually configuring IRQs, is a solution here. But it's not something I'll willing to take on.

But anyway! Here's how far I got with disabling... (attached pic)

I'll know later this evening if this is a cure. I'll also try other techniques, like setting the number of voices to zero before selecting presets...

that should be ok.

there's no way for irq sharing with something as chatty as USB to be possible. in win 98, ANY sharing was impossible. the card just can't wait for it's turn or skip it's turn. this will not change.