Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
HWINFO error with SB Live! driver since 5.2.5
#1
I have been using HWINFO (DOS) for some time. Prior to version 5.2.5 (e.g. 5.2.2), HWINFO works fine when SB Live! DOS driver (SBEINIT.COM, v5.0) is loaded in memory. However, HWINFO since 5.2.5 (including current version 5.5.0) will not work properly with the SB Live! driver loaded; it will show garbage info and/or crash while opening most pages under "Info" menu. Hope this problem will be resolved. Thanks a lot!
Reply
#2
Please tell me which exact items show garbage or crash.
If you remove the driver, does it work properly then?
Can you try to free additional system memory in case the SB Live driver is loaded if that helps?
Reply
#3
Martin Wrote:Please tell me which exact items show garbage or crash.
If you remove the driver, does it work properly then?
Can you try to free additional system memory in case the SB Live driver is loaded if that helps?

Currently I am using HWINFO 5.5.0 for testing. In "Info" menu, "Video", "Drive", "IRQ" and "DMA" will all show garbage or crash. If I remember correctly, "Mainboard" will also show some garbage in 5.2.5, which I tested in the past but don't have it now. On the other hand, HWINFO 5.2.2 (which I still have in the machine) does not have such problem (i.e. all items will be displayed fine).

If I don't load the SB Live! driver at all, HWINFO will work properly. The SB Live! driver cannot be unloaded once it is loaded in memory (unless restart).

I have tried to load only HIMEM, EMM386 (required by the driver) and the SB Live! driver (SBEINIT), but no luck. On the other hand, HWINFO 5.2.2 will work correctly in all cases.
Reply
#4
Does the SB Live! driver require EMM386? Having EMM386 loaded is not recommended, it can cause issues.
I'm not sure why it causes problems from v5.2.5, but it's possible that some features I added lately conflict with EMM386 or the SB Live! driver, but I'd rather bet on the EMM386.
Reply
#5
Martin Wrote:Does the SB Live! driver require EMM386? Having EMM386 loaded is not recommended, it can cause issues.
I'm not sure why it causes problems from v5.2.5, but it's possible that some features I added lately conflict with EMM386 or the SB Live! driver, but I'd rather bet on the EMM386.

Yes, the SB Live! driver does require EMM386. I understand EMM386 can cause issues, but HWINFO 5.2.5+ works fine with EMM386 alone (i.e. without SB Live! driver loaded) on my machine. I'm not sure what happened since 5.2.5 either, as HWINFO 5.2.2 or below does work correctly in all cases.
Reply
#6
Can you try to free as much memory as possible using EMM386 (load drivers high and use UMB)? It would require to do DEVICEHIGH for drivers and DOS=HIGH,UMB.
Reply
#7
Martin Wrote:Can you try to free as much memory as possible using EMM386 (load drivers high and use UMB)? It would require to do DEVICEHIGH for drivers and DOS=HIGH,UMB.

Yes, actually I already optimized the memory usage in my PC some time ago and it tries to load almost everything in UMB (provided by EMM386 with NOEMS option). Usually there is around 620-625KB free conventional memory. In my second post, I even tried to load only HIMEM, EMM386, and SBEINIT, and then run HWINFO 5.5.0, although the result is same.
Reply
#8
Could you make a screenshot or try to save a LOG (F2 key) of the garbaged screen so I can see precisely how it looks like?
Reply
#9
Martin Wrote:Could you make a screenshot or try to save a LOG (F2 key) of the garbaged screen so I can see precisely how it looks like?

Sure. I have tried to save a LOG file for each item in "Info" menu (see attachment, zipped):

HWINFO.LO1 - "Mainboard" (works fine)
HWINFO.LO2 - "Video" (garbaged)
HWINFO.LO3 - "Drive" (garbaged)
HWINFO.LO4 - "Peripherals" (works fine)
HWINFO.LO5 - "IRQ" (garbaged)
HWINFO.LO6 - "DMA" (garbaged)

(Tested with HWINFO 5.5.0 under MS-DOS 7, with SBEINIT loaded)

[attachment=0]


Attached Files
.zip   HWINFO.ZIP (Size: 2.35 KB / Downloads: 119)
Reply
#10
Hmm, this is very strange and very hard to determine why it happens..
If you try to load EMM386 only (without the SB Live! driver) does the problem appear too? Then I'll know if it's related to EMM or the sound driver.
Reply
#11
Martin Wrote:Hmm, this is very strange and very hard to determine why it happens..
If you try to load EMM386 only (without the SB Live! driver) does the problem appear too? Then I'll know if it's related to EMM or the sound driver.

The problem will not appear if only EMM386 (without the SB Live! driver) is loaded. It only occurs if the SB Live! driver is loaded in memory (BTW, I had already mentioned this in my earlier post). As the problem did not occur in version 5.2.2 or below, maybe a look at the changelog in 5.2.5 will help?
Reply
#12
I don't think it will help. The interaction with that driver might not be so easy to determine...

Choulin Wrote:
Martin Wrote:Hmm, this is very strange and very hard to determine why it happens..
If you try to load EMM386 only (without the SB Live! driver) does the problem appear too? Then I'll know if it's related to EMM or the sound driver.

The problem will not appear if only EMM386 (without the SB Live! driver) is loaded. It only occurs if the SB Live! driver is loaded in memory (BTW, I had already mentioned this in my earlier post). As the problem did not occur in version 5.2.2 or below, maybe a look at the changelog in 5.2.5 will help?
Reply
#13
Some notes:

* the SBLive emulation driver is considered as the least crappy one among such "drivers"
* YES it does require EMM386 and this fact is not properly documented
* such "emulation drivers" are "by design" inherently unreliable
* such "emulation drivers" are "stupid VCPI intruders"
* they intercept access to ISA SB ports using V86 mode for real mode applications and using I/O debug for protected mode applications, reportedly this has a chance to "work" in Ring0 too
* reportedly they need some "hardware support" (PCI to ISA DMA "redirection") and thus don't work anymore on some latest mainboards ... yeah :-)
* one possible hack would be to ZERO'ize out the debug registers in HWiNFO
* the "design" goal of such "emulation drivers" (fake hardware and fraud applications) eclatantly conflicts with the design goal of HWiNFO (properly detect hardware)
* the solution is to document this: don't use any (sound) emulation drivers when running HWiNFO (what about hacky USB emulations ???)
* please (Martin) look into the other documentation issues I had reported by Mail
* for good reasons I don't use and deprecate both EMM386 and such "emulation drivers" ;-)
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)