HWINFO error with SB Live! driver since 5.2.5

Choulin

Member
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!
 

Martin

HWiNFO Author
Staff member
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?
 

Choulin

Member
Martin said:
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.
 

Martin

HWiNFO Author
Staff member
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.
 

Choulin

Member
Martin said:
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.
 

Martin

HWiNFO Author
Staff member
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.
 

Choulin

Member
Martin said:
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.
 

Martin

HWiNFO Author
Staff member
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?
 

Choulin

Member
Martin said:
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]
 

Attachments

Martin

HWiNFO Author
Staff member
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.
 

Choulin

Member
Martin said:
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?
 

Martin

HWiNFO Author
Staff member
I don't think it will help. The interaction with that driver might not be so easy to determine...

Choulin said:
Martin said:
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?
 

DOS386

New Member
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" ;-)
 
Top