Prozactive

On a related note, I can't access any URL with adobe.com in the address again now. Is anyone else experiencing the same thing? This first happened several weeks ago and persisted for several days before everything suddenly went back to normal. I have no idea what's causing it. I checked my hosts file and other URL filters but didn't see anything amiss. I'm completely baffled. All of the adobe.com URLs are inaccessible with timeout errors.

Some long-delayed feedback on the modified DI1000DD.SYS and ASPIEHCI.SYS drivers per rloew... The modified DI1000DD.SYS does seem to allow progress past the former crash point where the divide overflow error occurred but eventually still results in the following error message: Your program caused a divide overflow error. If the problem persists, contact your program vendor. Note that this error message now occurs after Ghost 2003 is loaded, and has a blank gray Ghost 2003 opening splash screen window with the Symantec logo on the bottom as the background. That was not the case with the former divide overflow error. The modified ASPIEHCI.SYS does not seem to have any effect, however. The same divide overflow error continues to occur as before. @jds: I was able to finally get a USB 2.0 hub working with the PCI card and did some testing with it. The MDGx-modified Panasonic USB driver v.2.28 does not detect any devices attached to the hub, but the original v.2.27 version of the driver does, for whatever reason. Also, I was mistaken. That 1.0 GB external USB HDD was not NTFS-formatted as I thought, but FAT32 instead.

@duffy98: Glad it helped. I clearly remembered you asking that question before as I was also puzzled by the global hooks issue with SSM. @herbalist: Thanks as always for your thorough technical investigation of this conflict(s) between KernelEx and SSM. It looks like you've successfully duplicated the error that I experienced immediately after installing SSM for the first time. As I believe I stated in an earlier post, I got the exact same error with EXPLORER that you did as I clicked on the Start menu: EXPLORER caused an invalid page fault in module <unknown> at 0000:9eff049c. And while I also have Kerio 2.1.5 installed (per your strong recommendation), I did not experience the errors associated with it that you cited, probably because the previous errors occurred so quickly after installing SSM that I immediately disabled the associated KernelEx extensions. It certainly does sound like the conflict/errors are chipset-dependent. FWIW, I had to disassemble my laptop recently for some hardware repairs and I physically verified that I have the Intel 440ZX chipset, which apparently is a cut-back version of the 440BX chipset. And while I've never used them, apparently many virtual systems use the 440BX chipset in their emulation as a result of its broad compatibility. I still have not tested enabling KernelEx extensions for SSM on my desktop PC (which uses completely different chipsets) but when I do so I'll report back with the results.

duffy98, You asked this same question about global hooks a while back and Rick/herbalist answered it FYI.

By the way Rick, your links in post #21 don't seem to be correct. I presume you mean these two posts in the main KernelEx thread: link 1 link 2

I'm glad this thread has been resurrected for SSM-specific discussions. I meant to do so during the earlier discussion about KernelEx and SSM since it got completely buried in the main KernelEx thread with lots of other non-SSM-related topics and discussion. Regarding the conflict between SSM and KernelEx, I know it occurred on my old Toshiba laptop. Here is the requested system data per CPU-Z, v.1.56: CPU: Intel Mobile Celeron (Coppermine) 700 MHz, Family: 6 Model: 8 Stepping: 6 Chipset: Intel i440BX/ZX I can't recall whether the same conflicts occurred on my desktop PC or not. I may have gone ahead and disabled KernelEx extensions for SSM as a precautionary step based on my experiences with my laptop. I'll check to see if they occur with KernelEx enabled. If they do, I'll post the same CPU/chipset data for that system.

I can imagine. Unfortunately while I've done a fair amount of coding, I'm not a programmer and I certainly don't have the technical capability to do what you're doing. I'm very grateful for your work and hopefully you'll receive support from other technically competent members.

Wow. Great work rloew! I've located the specific bytes you cited but unfortunately I'm not able to test the patched driver as I do not have a HDD larger than 320 GB. The 1.0 TB HDD on which I got the "divide overflow" errors belongs to a friend. Maybe someone else can test the patch and report their experiences. On a related note, I meant to mention this earlier... I'm puzzled how dencorso is able to access his 1.5 TB HDD without any such errors. And as I discussed in an earlier thread, Ghost 2003 apparently has a "hard" 1.0 TiB size limit in its coding. I don't think dencorso specifically stated that he used Ghost 2003 to access his 1.5 TB HDD but I know he uses that program. And I don't know if he used DI1000DD.SYS but I also experienced the "divide overflow" error with ASPIEHCI.SYS and GUEST.EXE.

Well this thread kind-of fizzled out. I got burned out from all the time-consuming trial and error testing without any success, and the OP apparently completely lost interest too. No I have not yet but I plan on doing so. I do remember you mentioning that and I wanted to test it out for myself. I'll report my experiences when I get around to it. Yeah, I don't know. I can't think of any particular reason offhand why you're experiencing those problems either. Some brief updates: I was able to successfully use ASPIUHCI.SYS with DI1000DD.SYS on my laptop to access and write to an external USB HDD at USB 1.1 speed. It was quirky however in that my external USB HDD showed up twice (duplicate entries) within Ghost 2003 in the Check Disk option. As I previously mentioned, loading ASPIEHCI.SYS with the switches /D1 through /D3 allows DI1000DD.SYS to be successfully loaded without the hard lockups I experienced earlier. However I still cannot detect any USB devices connected to my USB 2.0 PCI card. I was able to do some more testing on that Verbatim 1.0 TB NTFS-formatted external USB HDD again. Both DI1000DD.SYS and ASPIEHCI.SYS caused a "divide overflow" error. Again, only ASPIDISK.SYS allowed successful access to the HDD.

I missed the new thread that was merged into the older (mistitled) long IE 6 thread and I really like the new title. Good job dencorso! I wasn't aware that WildBill finished his Win2000 KB2416400 update. It appears that SHLWAPI.DLL, MSHTML.DLL, and MSTIME.DLL are the 3 files that have been updated since his previous KB2360131 IE 6 update. And even though you specifically mentioned it dencorso, I didn't realize that WildBill updated MSHTMLED.DLL to yet a newer version in v.3 of that update. I thought he just updated it to that later version that Dave-H and I already had vs. his earlier release of the update.

Just checking... doesn't KB2436673 (MS10-098) supersede KB981957 (MS10-073)? Thank you so much for all the hard work, effort, and time obviously required to develop these updates!

Just to chime in with my experience. I tried that Verbatim FAT32 format utility a while back but it did not detect my USB HDD. I also tried the SwissKnife app recommended by someone else but it was a disaster. I finally used my tried and true GDISK method to manually partition and format the HDD with FAT32.

@dencorso: I've now done a fair amount of testing and can report that loading ASPIEHCI.SYS with those switches (/D1 through /D3) still does not allow it to detect any USB devices connected to my USB 2.0 PCI card. However, coincidentally or not, DI1000DD.SYS is now successfully loaded without the hard lockups I experienced earlier. I've also noted that the Panasonic USB drivers (especially the MDGx modified 2.28 driver) tend to hang at the point while scanning for USB devices after initializing all detected USB controllers. Replugging a USB device seems to consistently unfreeze the system and allow normal bootup to continue, albeit without the replugged USB device subsequently being detected. Yet another example of the quirky nature of this entire process. @jds: As I thought more about it, I've definitely used DI1000DD.SYS numerous times to access and write data to a 120GB FAT32 partition without any problems. I've also used ASPIDISK.SYS once to access and write data to a 1.0 TB NTFS partition via Ghost 2003. That's been the only time I've successfully used ASPIDISK.SYS to access any HDD, by the way. And I didn't think the formatting of a partition affected whether the driver could successfully access the USB device but I could be wrong.

Thanks dencorso and jaclaz. Coincidentally I read that first referenced link shortly before you posted it. And I'll try those new switches and see how they work. Also, I edited my previous post for the interest of technical accuracy. I no longer think I loaded all of the DOS USB drivers "high" when I got the second error. I did so many combinations it's become very confusing.

Thanks dencorso and jds for the replies, info, and advice. I think I'm throwing in the towel, as I've spent far too much time and effort in this ultimately futile quest to get those combinations of drivers working. And it's not even necessary, as I'm able to use the Panasonic drivers with DI1000DD.SYS to access all of my USB 2.0 devices so far. I was just baffled how dencorso was able to get options (iii) and (iv) to work, while I was not able to. @dencorso: Yes, as I stated in another recent thread, I just installed a new Syba VIA VT6212 USB 2.0 PCI card so I definitely have USB 2.0 capability which I've used and verified numerous times. My statement about being able to detect USB devices with Iomega's USB 1.1 drivers (ASPIUHCI and ASPIOHCI) was premature. As it turned out, that only occurred once and I could never get it to happen again. So to summarize the current situation, I cannot detect any USB devices connected to the Syba VIA VT6212 USB 2.0 PCI card with any of Iomega's drivers. I'm increasingly convinced that their drivers are incompatible with this particular hardware. I have, however, successfully used Iomega's ASPIUHCI.SYS driver countless times to access USB 1.1 devices connected to my motherboard's (ABIT KG7-RAID) USB ports. Also, I don't think the hard lockups/incompatibility between DI1000DD.SYS and ASPIEHCI.SYS are affected at all whether the Iomega driver detects or fails to detect any USB devices. Maybe I'm wrong, but that's how it appears to me watching the drivers load and the status messages. Thanks again for your advice about using DEVLOAD to load the drivers. I may eventually do that just to see if it makes any difference. @jds: I encountered the exact same nonsensical error message you cited after loading the Panasonic USB drivers and GUEST.EXE "low" into conventional DOS memory: Write protect error reading drive A Abort, Retry, Fail? The system became extremely unstable and generally crashed at varying points afterwards, requiring either a warm or cold reboot. Interestingly, I initially got this slightly different error message when loading all of the drivers "high" into upper memory: (EDIT: I believe that is incorrect. I loaded most/all of the DOS USB drivers "low" but used JEMM386 and other memory managers to enable upper memory for other drivers.) Write protect error reading drive 9 Abort, Retry, Fail? Selecting "Retry" immediately generated a fatal exception 06 error in JEMM386.EXE (one of the memory managers that I use). I also did note your past statement about DI1000DD.SYS and ASPIDISK.SYS being unstable for partitions 64GB or greater in size. That's interesting, and I'm not sure my personal experience completely corroborates your statement. I'll have to pay close attention to that in the future. Offhand, I can think of several examples where I've accessed and written to partitions considerably greater than 64GB, both FAT32 and NTFS formatted.

Another brief update. Utter failure. After extensive trial and error testing, changing various parameters, etc., I cannot get options (iii) and (iv) to work whatsoever. I'm completely baffled how dencorso and others (?) are able to do so. Loading the various drivers "low" vs. "high" does have an effect but does not allow GUEST.EXE to work with the Panasonic USB drivers. DI1000DD.SYS still causes a hard lockup with ASPIEHCI.SYS no matter how the drivers are loaded ("low" or "high"). And ASPIEHCI.SYS cannot detect any of my USB 2.0 devices. I may fill in some of the details later but that's the bottom line. I'd be interested to hear how anyone is able to get those options to work.

Just a quick update. Apparently loading the drivers in upper memory DOES have an effect, especially with GUEST.EXE. I now have to do more extensive trial and error troubleshooting to narrow down where and how the errors are occurring. It also may involve the particular memory managers/drivers that I'm using. And I still cannot detect any USB devices with ASPIEHCI.SYS for some reason, even though I can detect them with Iomega's USB 1.1 drivers.

Thanks herbalist for taking the time and effort to troubleshoot this issue. Sorry I was slow responding but your reply got buried in the recent deluge of posts about browsers, etc. Speaking of which, I wonder if this discussion could be moved to one of the SSM threads, even though it does involve KernelEx. Anyway, that's puzzling you weren't able to replicate the errors. As I said, they occurred immediately after I installed SSM several months ago. I've also suspected possible RAM and/or other hardware problems were involved with my recent system instability but I've run several passes of Memtest86 and my system RAM passes with flying colors. I've also run Memtest86 and Prime95 several times in the past and I've never encountered any errors, so I'm very confident I don't have any hardware issues (at least in those areas). I also have not installed any new printer drivers. My system has become much more stable again recently for some reason and I have not encountered those BSoDs again, thankfully. Also, these system stability problems were not an issue back when I installed SSM. And dw2108 apparently had similar issues with SSM and Explorer back in post #1040, which initiated my response and subsequently all this diagnostic work from you.

@jds: This is what led me to say you were somewhat confused about ASPIEHCI.SYS. In any case, it's a minor point but I'm glad dencorso took the time to check and clear things up. We're all using the same drivers. Yes, I'm also somewhat confused about the versions of USBASPI.EXE. MDGx would be the source for a definitive answer, but I suspect he decided to increment the version number of his modified (possibly older) driver. I've made the changes in CONFIG.SYS to load the drivers into conventional "low" memory and I'm about to test them shortly. We'll see if it makes any difference. I tend to think it won't but you never know. It may be my particular hardware that's causing the incompatibility.

Thanks dencorso for your reply and the info. I am loading ASPIEHCI.SYS with the /int /all switches. I am also loading the Panasonic USBASPI drivers with the /norst switch. The only possible difference is I am loading the drivers and GUEST.EXE into upper memory (using DEVICEHIGH for the drivers and LH for GUEST.EXE). This has not caused any problems previously but I will probably experiment loading them into conventional "low" memory to see if it makes a difference. DI1000DD.SYS definitely causes a hard lockup with ASPIEHCI.SYS (option iii), while GUEST.EXE appears to stall out indefinitely while trying to assign a drive letter after the Panasonic USB drivers are loaded (option iv). Thanks for the info about DEVLOAD and DEVLOD. I was not aware of them and I may try using them as a last resort. I have also verified all of the MD5 hashes. As a minor point of clarification (which also apparently confused jds), viewing ASPIEHCI.SYS in a hex editor shows the following string: Iomega ASPI USB-EHCI 1.0 V.13 09 May 2003 Copyright © 2003 Iomega Corporation. which implies to me that it's 1.0 version 13 (dated 09-May-2003) as opposed to "v.13 09 of 2003" as you've stated numerous times. In any case, we're all using the same file. Thanks again for your help and I'll report back with any developments.

@dencorso: I tested the various new combinations of drivers but I was unable to get options (iii) and (iv) to work. Option (iii), ASPIEHCI.SYS + DI1000DD.SYS, froze the system after loading the Iomega ASPIEHCI.SYS driver, displaying the status "No Devices Found." That was the step in CONFIG.SYS where it loaded DI1000DD.SYS. This was a hard lockup too, where ctrl-alt-del did not reboot the system, requiring use of the reset button to reboot the system. I was unable to detect any of my USB 2.0 test devices with the Iomega ASPIEHCI.SYS driver either, further confirming my experience that the driver has very limited compatibility. Option (iv), Panasonic USB drivers (either USBASPI.EXE or USBASPI.SYS) + GUEST.EXE, stalled after detecting USB devices, displaying the status "Finding a drive letter for your Iomega drive..." This was not a hard lockup. The keyboard was still responsive and I could use ctrl-alt-del to reboot the system. I'm puzzled how you and others were able to get these combinations to work.

I'm back. My laptop has increasingly been more unstable recently with frequent Windows/apps crashes and BSoDs for some reason, some of which I described in the Revolutions Pack thread. I've wondered whether SSM is a contributor to this, but anyway. Yes I understand. Unfortunately (?) I have not installed any of the unofficial service packs but I've updated the system piecemeal with just about all of the official Microsoft and unofficial MSFN/MDGx updates, including KernelEx (obviously) and Revolutions Pack fairly recently. At the time I installed SSM, I had installed KernelEx 4.5 RC 1 and Revolutions Pack 9.6.5. HTH

Thanks, herbalist, for your long and thorough reply. I was going to reply in more detail but right now I'm having more problems with my laptop. But, yes I just verified the MD5 hash.

Excellent technical discussion. I only have time to quickly address this particular question for now. The following is from the readme file from MDGx's modified driver. USBASPI.EXE is a modification of the recently released Panasonic native DOS USB driver USBASPI.SYS ver 2.28. I found a reference to that new version on a recent MSFN post: http://www.msfn.org/board/index.php?showtopic=40561 http://www.msfn.org/board/index.php?showtopic=114868&pid=753965 The modification was necessary as I experienced system lockups on PCs where the BIOS supports some USB mass storage devices, such as USB floppy drives, USB ZIP drives and USB CD-ROM drives, but, for example, not all USB memory sticks or hard drives. With the command line switch /w the driver now pauses *after* the USB controllers have been initialized. When USB mass storage devices are connected at that point, the lockups no longer occur. The original functionality, that is, the driver pauses *before* the controllers are initialized is still possible with the following command line switch: USBASPI.EXE /w /w

Yes, from DOS essentially. Actually it's a dual-boot system so I did it from WinXP. I rename the older file with a different extension then replace it with the updated file. Currently I'm using the Browseui.dll from WildBill's KB2360131 IE 6.0 SP1 update but at the time of the errors I was using the KB982381 version. I'm still VERY slowly learning how SSM works and how to configure and use it properly. It seems to be a very powerful tool albeit somewhat complex and confusing to use. Some of the menus, layout, and structures aren't intuitively user-friendly and obvious, at least to me, but I'm slowly getting familiar with them. I think you said in that other thread that you were working on some user guides for SSM. If you ever find the time to finish them, that would be a great help! Thanks again for all the help and excellent technical advice. Oh okay about the File menus in Windows Explorer. Again, since it's been several months since all this occurred, my memory is a little fuzzy but I don't specifically recall any problems with those menus. However, I think the Start button errors occurred so quickly after installing SSM that I didn't have much time or opportunity to use the system before disabling those KernelEx extensions. And yes, "block process creation" is checked in "Program behaviour\When user interface is not connected and no rules exist:" That must be the default setting as I don't really understand what that means. Good luck with winter. It sounds nasty in the Midwest. We're just starting to get the big storm front blowing in here in the South.