1st: Are you using a serial device over a different output? I.e. USB to 9 pin serial cable? If so try removing the driver for the device and reinstalling it and/or looking for a new driver from the supplier.
2nd: Make sure the COM port/device you're using isn't sharing an IRQ with anything else. You can check in device manager. You can also check in your bios but be careful changing things there, you may fix your issue but create several others.
edit: Is there anything in C:\windows\minidump ? Substitute "C:" with whatever your boot drive is.
Last edited by D1G; 11-08-2009 at 12:20 AM.
Reason: Posting new stuff as I think of it :)
I've been trying to replicate your problem and I can't. I'm using a different model Dell (it shouldn't matter) laptop and everything is working as it should on Windows XP SP3. I can download and switch between modules without issue. I'm downloading the same program that's currently in them but w/e.
Do you have AV on your machine? There is a lot of malware in the wild that can cause these same issues/errors. Have you found a solution?
Ok. First I went to the link you sent on the serial entry in the registry. There are no parameters in there as described. Yes I have lots of entries in C:\windows\minidump. I opened with notepad and there's a lot of jibberish and alot of .sys filenames. Now, I'm going to uninstall the drivers for the S2 Innovations USB to Serial adapter that I use and the drivers for the Edgeport USB I have as a back-up and see what happens. Yes I use A/V software. Symatec Antivirus Corporate Edition so I would hope that I am reasonably clean as far as viruses and malware, etc. I let you know what happens after uninstalling the drivers.
We have an identical laptop at the office. I'm going to try to install just the serial tunnel and CommPro N2 and see how that goes. So far, I have tried on another dell laptop here at home (different model) and got the same failure. I wish I could isolate this to a particular machine... or something.
Just an update... I installed CommProN2 on the identical laptop and the serial tunnel utility. I connected to our DEMO FX20 at my desk with an FX07 connected. I opened the connection on COM5 which did not exist on the laptop, connected to the FX20 with COM5 in CommProN2. I downloaded the controller with a program 3 times without fail. Commissioned the controller, looking at all points. Tried to download again and got the same failure blue screen of death vserax.sys. There is next to nothing loaded on the laptop like there is on mine (yes, I'm a geek). I guess that this eliminates the laptop issue. Also, as I've discussed with Johnson, the version of Serial Tunnel is 1.1 that is installed. The text document that also gets installed talks about version 1.2.
Your test results on two different computers effectively rules out anything funky with the computer. So, I would look closer to the CommPro software and the driver you mentioned. Remember in Windows, device drivers are "trusted components" and as such have minimal O/S trapping if they go awry and have full access/control of the hardware and memory... so if they have a bug they can easily take down your system. Since you are seeing a complete crash (i.e. Blue screen), then my feeling (and is confirmed by the resulting blue screen info) is that it is a device driver bug... This will not be something you will be able to fix (device driver needs to be investigated and possibly modified), however, it seems that whatever you are doing, etc seems to create a re-creatable scenario...Although this seems bad, the fact that it is relatively re-creatable is a tremendous benefit to the software vendor, as it should be quite straightforward to sort it out. Hopefully the software vendor will be humble enough the acknowledge that their may be a bug in their software/driver and work with you towards a suitable solution.
I agree that it is most likely a bug in one of the two drivers and/or a conflict between one of those two and the application. The problem with relying on the BSOD message is that it only displays the service that caused the crash offering little to no stack traceback. Without a way to prove the problem didn't develop elsewhere culminating in the crash it can be difficult to get software vendors to even consider their code could be flawed (little sarcasm there).
The minidump and/or crash dump files should look like "gibberish", they mostly contain completely raw memory contents. minidumps explained but they provide the only "real" debugging info available after an application crashes.
I am satisfied at this point that it is a driver issue with the serial tunnel application. I downloaded, installed and ran Windows Debugger last night to analyze the minidump files and it points to the same thing. Any thoughts on the version discrepancy with serial tunnel? Johnson had no clue about this but said they would check with tridium. No reply yet. Big surprise.
<snip>Without a way to prove the problem didn't develop elsewhere culminating in the crash it can be difficult to get software vendors to even consider their code could be flawed (little sarcasm there).
Good day D1G,
Indeed you are correct on this. Sadly the arrogance of some software (and hardware) vendors is amazing. Although I, too, have an ego I have enough experience with software (and hardware) to know that bugs can happen anytime and on any revision...
That being said, with my customers I assist them to the best of my ability to determine where the root cause is. I always design in diagnostic software (or firmware, hardware) into our products to allow for these debugging/diagnostic scenarios. Or at times, I will write specialty applications to capture data, etc for our analysis. Only then can I determine if it is something to do with our stuff or perhaps something else.
I really appreciate all of your help with this issue! I seem to be the only one in the world with this problem - yet I can duplicate the result on (4) different computers.
Good day MrEddySpag,
The software vendor should be "all over you", as you have determined a mostly repeatable scenario... which Like I said earlier, is the holy grail in software (and hardware) debugging.
As for being the "only one in the World" having this problem... not likely by a long shot. It is more likely that perhaps you were the first to "discover" this issue. In one sense, you are actually "helping" the vendor to improve their system by discovering such a bug!