Hi all. I had a nasty BSOD experience with Scope v5 RC yesterday (Win XP SP3 with PowerPulsar + E-mu 1820). I was just playing a few presets in Adern's Xor that I'd loaded into the default project window and the PC crashed to the dreaded 'driver irql equal or not equal' (or whatever it is) BSOD with the Scope driver mentioned as the culprit. Curiously, in all the years I've had Creamware/Scope cards in my PC, this is the first time I've had a BSOD directly caused by the driver. Apart from the new v5 software nothing else has changed in the PC since I was using v4. I'm concerned that this doesn't bode well for the stability of v5. Has anyone else had a similar stability problem? I've e-mailed SonicCore support with my BSOD report.
Regards,
David
Nasty BSOD w Scope v5 RC
Re: Nasty BSOD w Scope v5 RC
sure, send it to them.
the message is a little misleading, most likely. that sounds like a harware problem, the Scope driver ran into the problem(BSOD is almost always hardware related). if the problem happens only with xor, and it's repeatible, then it may be a Scope issue. if it is sporadic, it's probably something dying on the motherboard, video card or power supply. i'm just guessing based on previous experience, of course...
the message is a little misleading, most likely. that sounds like a harware problem, the Scope driver ran into the problem(BSOD is almost always hardware related). if the problem happens only with xor, and it's repeatible, then it may be a Scope issue. if it is sporadic, it's probably something dying on the motherboard, video card or power supply. i'm just guessing based on previous experience, of course...
Re: Nasty BSOD w Scope v5 RC
'driver irql equal or not equal' is an irq conflict, or more specifically something tried to access a memory area already in use (hardware is accessed by using memory locations.) There are actually other things that can cause this, so garyb is correct in his information as well, but chances are you need to look at the board id's (if you have multiple boards) and your irq sharing. Board id's swapping would be my first thing to check at least...(since that will change the pci slot being used as the 'master').
Re: Nasty BSOD w Scope v5 RC
there you go, more detailed info...
Re: Nasty BSOD w Scope v5 RC
Actually on reread I notice he said Powerpulsar, as in singular Scope Pro.
In that case I think I'd just start by making sure the card & well seated and the machine isn't running hot, and then try to see if you can isolate repeatable behaviour. If it *is* Xor or a specific set of circumstances with Scope then you should perhaps see the behavior again. Think about the other things you were doing, such as passing a large amount of midi data to & from the OS (or processing a high number of audio streams etc.) If it IS midi related or something similar it shouldn't take too long to figure that out.
If it seems random or just due to 'using' Scope (sometimes just with the GUI & not a midi controller) then look at IRQ sharing and other common issues. These forums cover in great detail the resource sharing issues for Scope that are compounded by ACPI and specific motherboard implementations (for instance I have a workstation board which has non-PCIe devices mapped to IRQ's 1 through 24 & IRQ's 48 through 56 mapped to my graphics card & memory MCH).
Something to consider is that Xp doesn't reserve the resources the old driver had through some magical means. So the new driver may well have wound up sharing with something else, or be sharing with the same devices as before but consuming resources in a way it didn't when it first loaded the HAL (on initial install). This isn't necessarily something that SonicCore is responsible for (the shifting around of resources). You may also have added/removed/enabled/disabled additional peripherals over time and wound up with 1 device happily 'sharing' with the Powerpulsar during its 'original' (4.5?) install. But now on initial install of the 5.0 driver it was instead allocated resources that share with a device it's 'less than happy' with just through sheer happenstance (assuming it couldn't find the appropriate resources free all on its own.)
But if you think it's Scope 5 then try to isolate it more. An IRQL error might give some memory dump info you could send to SonicCore, but repeatable circumstances that caused the event will be much more useful imo.
In that case I think I'd just start by making sure the card & well seated and the machine isn't running hot, and then try to see if you can isolate repeatable behaviour. If it *is* Xor or a specific set of circumstances with Scope then you should perhaps see the behavior again. Think about the other things you were doing, such as passing a large amount of midi data to & from the OS (or processing a high number of audio streams etc.) If it IS midi related or something similar it shouldn't take too long to figure that out.
If it seems random or just due to 'using' Scope (sometimes just with the GUI & not a midi controller) then look at IRQ sharing and other common issues. These forums cover in great detail the resource sharing issues for Scope that are compounded by ACPI and specific motherboard implementations (for instance I have a workstation board which has non-PCIe devices mapped to IRQ's 1 through 24 & IRQ's 48 through 56 mapped to my graphics card & memory MCH).
Something to consider is that Xp doesn't reserve the resources the old driver had through some magical means. So the new driver may well have wound up sharing with something else, or be sharing with the same devices as before but consuming resources in a way it didn't when it first loaded the HAL (on initial install). This isn't necessarily something that SonicCore is responsible for (the shifting around of resources). You may also have added/removed/enabled/disabled additional peripherals over time and wound up with 1 device happily 'sharing' with the Powerpulsar during its 'original' (4.5?) install. But now on initial install of the 5.0 driver it was instead allocated resources that share with a device it's 'less than happy' with just through sheer happenstance (assuming it couldn't find the appropriate resources free all on its own.)
But if you think it's Scope 5 then try to isolate it more. An IRQL error might give some memory dump info you could send to SonicCore, but repeatable circumstances that caused the event will be much more useful imo.
Re: Nasty BSOD w Scope v5 RC
If you DO want to check on IRQ/resource sharing here's my take:
Since ACPI complicates this picture so much the 'common lore' here is to disable your motherboards ACPI support (APIC controller) and resolve IRQ conflicts from there since they're now 'visible' within Windows (no APIC/ACPI support to steer things onto virtual IRQs.) That's the easy way, and in fact also points at my preferred method (which takes more time.)
I like to take a linux OS that I can fit on a usb drive or small partition somewhere and customize it to disable ACPI support. One easy way to do this is just to disable your APIC/ACPI support in your BIOS & install from linux install media to a usb drive that you can boot to (Damn Small Linux is one choice for a tiny distro that still has a GUI). It might take a few tries to find something that will sort out the kernel for you, but then simply boot to that and take note of how resources are shared. Or I actually just use one of the linux-based replacements for a 'bootable disk' (instead of the DrDos/OpenDos etc variants) and the appropriate shell support for digging into the mapped resources. An even simpler way if you can get the timing right is to hit pause/break on initial boot with your BIOS set to show all POST results during boot.
However you go about it, the idea is that you're getting the same picture of resource sharing that removing ACPI from windows gives without having to actually DO that (and reduce Windows functionality imo.) Basically, getting this non-ACPI IRQ 'map' helps you to 'fix' whatever hardware sharing is causing problems with Scope outside of windows. In my experience I've found that ACPI doesn't really cause problems, unless of course there are other devices that still have issues with resource sharing--but you wouldn't have a Creative Labs card as well, would you?
Lastly, the method some find the 'easiest' is just to move your card around until it's happy. If you do this with ACPI and plug&play enabled you're effectively just gambling, but persistance has still paid off for many.
Since ACPI complicates this picture so much the 'common lore' here is to disable your motherboards ACPI support (APIC controller) and resolve IRQ conflicts from there since they're now 'visible' within Windows (no APIC/ACPI support to steer things onto virtual IRQs.) That's the easy way, and in fact also points at my preferred method (which takes more time.)
I like to take a linux OS that I can fit on a usb drive or small partition somewhere and customize it to disable ACPI support. One easy way to do this is just to disable your APIC/ACPI support in your BIOS & install from linux install media to a usb drive that you can boot to (Damn Small Linux is one choice for a tiny distro that still has a GUI). It might take a few tries to find something that will sort out the kernel for you, but then simply boot to that and take note of how resources are shared. Or I actually just use one of the linux-based replacements for a 'bootable disk' (instead of the DrDos/OpenDos etc variants) and the appropriate shell support for digging into the mapped resources. An even simpler way if you can get the timing right is to hit pause/break on initial boot with your BIOS set to show all POST results during boot.
However you go about it, the idea is that you're getting the same picture of resource sharing that removing ACPI from windows gives without having to actually DO that (and reduce Windows functionality imo.) Basically, getting this non-ACPI IRQ 'map' helps you to 'fix' whatever hardware sharing is causing problems with Scope outside of windows. In my experience I've found that ACPI doesn't really cause problems, unless of course there are other devices that still have issues with resource sharing--but you wouldn't have a Creative Labs card as well, would you?
Lastly, the method some find the 'easiest' is just to move your card around until it's happy. If you do this with ACPI and plug&play enabled you're effectively just gambling, but persistance has still paid off for many.
Re: Nasty BSOD w Scope v5 RC
Thanks for all the helpful suggestions, guys. I'd planned to switch to a new motherboard with more RAM anyway, so hopefully this will take care of most failing hardware issues. But one thing I should point out is that this PowerPulsar has been happily working without any BSODs for 5 years, and it's only since installing Scope v5 that this problem has surfaced. This sort of BSOD can occur with driver issues and my money is still on the Scope driver. I've yet to hear back from SonicCore, though.
Regards,
David
Regards,
David
Re: Nasty BSOD w Scope v5 RC
davide37 wrote:...This sort of BSOD can occur with driver issues...
valis wrote:Something to consider is that Xp doesn't reserve the resources the old driver had through some magical means. So the new driver may well have wound up sharing with something else, or be sharing with the same devices as before but consuming resources in a way it didn't when it first loaded the HAL (on initial install). This isn't necessarily something that SonicCore is responsible for (the shifting around of resources). You may also have added/removed/enabled/disabled additional peripherals over time and wound up with 1 device happily 'sharing' with the Powerpulsar during its 'original' (4.5?) install. But now on initial install of the 5.0 driver it was instead allocated resources that share with a device it's 'less than happy' with just through sheer happenstance (assuming it couldn't find the appropriate resources free all on its own.)
Re: Nasty BSOD w Scope v5 RC
There is a known incompatibility between Scope and the Emu cards, as well as with some of the Creative SB cards. I've had Emu cards forever (I worked at Emu way back in the modular days, and I wrote software for the early Proteus and Morpheus synths), but I never could get my Pulsar card to work with the Emu cards. For that matter, I couldn't get the Kyma Capybara cards to work with either Emu or Scope cards. Kyma now uses firewire, so that issue is moot, not sure if Xite will coexist with Emu.davide37 wrote:Thanks for all the helpful suggestions, guys. I'd planned to switch to a new motherboard with more RAM anyway, so hopefully this will take care of most failing hardware issues. But one thing I should point out is that this PowerPulsar has been happily working without any BSODs for 5 years, and it's only since installing Scope v5 that this problem has surfaced. This sort of BSOD can occur with driver issues and my money is still on the Scope driver. I've yet to hear back from SonicCore, though.
Regards,
David
Bottom line, since Scope duplicates all the Emu functions, you don't really need the Emu card. You can set the STS-3000 to read the Emu/Creative SB2 sample libary. My default Scope boot up runs the 8MB Emu Gen MIDI sample set, which sounds way better than the Microsoft/Roland default set. Newer motherboards now have audio chipsets built in, and they work fine with Scope; but I've often run with Scope as my only sound card, using the STS-3000 for Gen MIDI. Worked fine with any game I ever tried.