There is no special order of events needed to trigger a crash as long as the timebase is 200ms or slower. But here's an example:
One scope window displayed. Set TB to 200ms/div. Watch only channel A display, no channel B even though it is also on. Set TB to 1s/div and wait 10 seconds, and "psw32.exe has encountered a problem and needs to close" appears.
Any other changes to the settings at 200ms or slower will also trigger a crash.
Could you send a .pss file so we can recreate the exact settings as you. What you say is different to the screen shot that you have. So if you can Save As , then choose Save as Type -> Setup Files (*.pss)
Just got my 3424 today and have identical problems with my system crashing at 200 ms/div. I also see the CPU utilization going to 100% and the only way to recover is reset the PC or unplug the 3424.
My machine is a 2 year old pentium running Win2000 with 1 GB of DRAM.
I'm using the latest app software, but not the driver from the earlier post. How do I install it?
Unfortunately, all of my data collection is at 200 ms/div and slower, so I'm stuck until we get this working.
I too am having problems - I'm running with a good spec HP xw4300 workstation using Windows 2000 - this is with a brand new 3204 with R5.16.2 software installed straight from the CD.
When I record with a timebase of 1 second per division, two A/B channels, it seems to very reliably give a Blue Screen of Death after a varying length of time - at the moment I have not got it set up to save the BSOD details, but it is showing NMI memory problems.
I wondered at first whether this was in some way connected with the other Apps I am running (e.g. HyperTerminal) but have confirmed this happens even when PicoScope is the sole program running.
Here is the BSOD information that currently appears on my PC *every* time I use the PicoScope3204 - this was with a 500mS timebase, and happened while I was setting up the scaling for the second channel.
The rapidity with which the crash happens is making the scope almost useless for me.
I have not yet installed the revised DLL, since the original problem description did not seem to match the symptoms I am seeing.
I've now updated from the original version 3.2.4.0 DLL file to the newer 3.2.8.0 one that is in the ZIP on page 1 - it's been running now continuous on a 2-second timebase for a solid hour, so I am hopeful this is going to be cleared for me.