System Info causes crash in Windows 10

[virtualnetwork]

Sounds like you're getting closer to solving it. The next UVK_debug contains:

Debug break point 1
Debug break point 2
Debug break point 3
Debug break point 10
Debug break point 11
Debug break point 12
Debug break point 14
Debug break point 16

[Fred]

OK, just this one more, if you don't mind.

debug.zip

(1.92 MiB) Downloaded 253 times

Thanks.

[virtualnetwork]

I don't mind at all
The next UVK_debug contains:

Debug break point 1
Debug break point 2

[Fred]

Ok, in this one, that issue should be fixed. Assuming there are no more bugs, it should not crash anymore.

Please download and try:

debug.zip

(1.92 MiB) Downloaded 267 times

Thanks

[virtualnetwork]

Problem solved! System Info is now working and no longer crashes. Here is the content of the latest UVK_debug:

Debug break point 1
Debug break point 2
Debug break point 9
Debug break point 10
Debug break point 11
Debug break point 11
Debug break point 11
Debug break point 11

What caused this error and why did it only appear on a few machines while most were unaffected by it?

[Fred]

I have a function called _GetSMBiosInfo(), which retrieves BIOS, motherboard, RAM and CPU information.

Initially it tries to get the info by reading the raw SMBIOS tables. If that fails, it tries to get the info through WMI.

The problem was caused by a missing security check in that function. It was only happening when the the function failed to get motherboard info from the SMBIOS tables, which explains why it only happened in some computers.

This is the code statement that was making the crash:

Code: Select all

if (2 != pdata[tableindex]) break;

It should be like this, instead:

Code: Select all

if (-1 == tableindex || 2 != pdata[tableindex]) break;

Thanks again for your help. I will release an update soon.

[Fred]

Speaking of which, can you please tell the make and model of the affected machine?

[virtualnetwork]

Thank you for identifying and solving the problem so quickly. The affected machine was an HP a1640n desktop PC. Here's a summary of the BIOS:

SMBIOS 2.4 present.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: Phoenix Technologies, LTD
Version: 3.15
Release Date: 02/05/2007
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 1024 kB

In the conditional

Code: Select all

if (2 != pdata[tableindex]) break;

I'm guessing that "2" refers to the header code for the motherboard information in the SMBIOS table ("0" would be the BIOS header code), and if it can't get the info from SMBIOS it will go into an infinite loop. Is that correct?
But it's not clear why this only happened in Windows 10, not Windows 7 or XP which reside on separate partitions on the same machine.

[Charger440]

My guess is Windows 7 and XP do not use the BIOS in the same way that windows 8 and 10 do. On those systems Fred might not even be trying to check the SMBIOS info.

Just a thought....

[virtualnetwork]

That's a possibility. Another reason might be that the error occurs in UVK_en64.exe; but it never runs in Windows 7 or XP because they are 32-bit (which I should have mentioned earlier).

[Charger440]

That could be. It's my natural assumption that 7 will be 64 bit and XP will be 32 bit. Then I just assume most all Windows 10 versions are 64 bit. As far as the code base goes, it should be very similar between 32 and 64 bit.

[virtualnetwork]

Yes, and in the case of XP there are few copies of XP Pro x64 because of the compatibility problems with 16-bit and some 32-bit software and MS-DOS.

[Charger440]

Yea XP 64 was kinda odd. It's almost easiest to describe it as running in a virtual machine. I was the first consumer version of Windows to "support" 64 bit and as such was really clunky at it I think.

[reggaemanu]

Same problem today with a windows 7 64bits machine fresh install
(motherboard gigabyte h67ma-usb3-b3 with a Core i3 2105 CPU)

[Fred]

Hi Manu. Did you download the debug build and test to see if the problem was solved? Thanks.

[reggaemanu]

Oh, I didn't even think about it
Let me try...

[Fred]

virtualnetwork, you're right again. Actually the 2 means BaseBoard, not Motherboard. That was actually part of the problem, because there may be more than one baseboard. So I had to loop through all the boards until I find one which table offset 13 is 10(0Ah), as shown in the picture below.


The problem with these machines, and I'm starting to believe they are all HP, is that they have no BaseBoard with 0Ah at offset 13, so Motherborad info is retrieved through WMI. I would surely like to know how many baseboard tables they have, and what is the value of the BYTE at offset 13.

[reggaemanu]

Worked fine and I have the same debug file as virtualnetwork

Code: Select all

Debug break point 1
Debug break point 2
Debug break point 9
Debug break point 10
Debug break point 11
Debug break point 11
Debug break point 11
Debug break point 11

[Fred]

Thanks, Manu. Is the displayed motherboard info correct?

[reggaemanu]

Yes, it say "Gigabyte Technology Co., Ltd. H67MA-USB3-B3 x.x"
But it also say the exact same thing for Computer