HWINFO 32.411.1844 hangs upon return from standby

[sdrubble]

Hi,

I have been using HWINFO32 on and off for a few years and versions, mostly on the same machine - it's a (now OLD ) Asus EEEPC 901 netbook (Intel Atom N270), with no HDs and a couple of smallish - and slow - SSD drives.

The reason for the 'and off' part is because of some random freezes which in the past I've never bothered to really investigate... :dodgy: but this time around I might wish to become just a *little* more involved with the issue.

The symptom is: upon returning from stand-by (but not EVERY time) HWINFO32 will be eating up 50% of the processor (both sides of the hyperthreading). Will resist all attempts to kill process. Will survive a logoff, so I have to reboot the machine.

I was just looking at the bug report here: http://www.hwinfo.com/forum/Thread-...elf-up-unable-to-close-and-100-one-core-usage . There are some similarities, but the OP says the issue was solved with 411.1827 (64-bit), while I'm using 411.1844 (32-bit).

You've asked in that other post about any other monitoring tool being used in parallel. I DO use Crystal DiskInfo tool for monitoring USB hard drives.

Maybe you can convince this lazy fella here to open a REAL bug report in the proper manner... while I'm wondering how it could be done since the issue happens in a seemingly random fashion.

Cheers

 

[Martin]

I don't think this issue is really related with the other one you mention. There could be several other reasons and if you want me to investigate this I need the HWiNFO Debug File capturing the problematic situation. Enable Debug Mode and after you reproduce the hang, reboot the system and grab the HWiNFO32.DBG file it produced. Then I can analyze it and hopefully come up with a solution.

 

[sdrubble]

I don't think this issue is really related with the other one you mention. There could be several other reasons and if you want me to investigate this I need the HWiNFO Debug File capturing the problematic situation. Enable Debug Mode and after you reproduce the hang, reboot the system and grab the HWiNFO32.DBG file it produced. Then I can analyze it and hopefully come up with a solution.

Well, I can surely do that... but pls tell me, since the problem is a bit random: how large should the .DBG file become after, let's say, a week or so ?

 

[Martin]

Ah, that will be very large.. Hard to estimate the exact size, since that depends on several factors.
If it occurs only after resuming from Stand-by, then you might try to speed-up the process by performing a test of constantly performing Sleep/Resume cycle sequences. This should invoke the issue much sooner.

 

[sdrubble]

Thx Martin...

I've just enabled 'Debug mode', restarted HWINFO, double-checked and it's indeed enabled.

But... there's no .DBG file inside HW's directory... does it take a while for the file to start being written ?

 

[Martin]

The DBG file is created during runtime and it's locked (you cannot access it) while HWiNFO is running. When you close it, or if HWiNFO crashes and you reboot the system, you can access that file.

 

[sdrubble]

The DBG file is created during runtime and it's locked (you cannot access it) while HWiNFO is running. When you close it, or if HWiNFO crashes and you reboot the system, you can access that file.

Well, I have re-started HWiNFO a number of times and NO DBG file shows up...

Would this possibly have to do with me not using the 'installable' version ? I just run the .EXE manually from a folder...

 

[Martin]

No, that shouldn't matter. From which drive are you running it? Is it maybe read-only?

 

[sdrubble]

No, that shouldn't matter. From which drive are you running it? Is it maybe read-only?

Well, I solved the no-DBG issue after a LOT of running in circles . After fiddling with a sticky read-only flag that wouldn't (and still won't) go away from the folder, folder permissions, shortcut permissions and run-as-administrator, I finally found the issue: the SHORTCUT where I ran HWINFO from had an empty 'Start in:' field. Go figure... :-/

Now the DBG file appears as soon as HWINFO is started (triple-tested !!!)

I also noticed that the DBG file was shown as having 0 bytes, until HWINFO was brought down a couple minutes later and it suddenly had 300 Kbytes... may I ask if this behavior would be also true for a day-long session ? :huh:

Cheers !

 

[Martin]

I'm glad that you finally found why it didn't produce the DBG file. Indeed, HWiNFO relies on that setting.
Yes, seeing the DBG file as 0 bytes during it's locked (HWiNFO running) is normal behavior.

 

[sdrubble]

I'm glad that you finally found why it didn't produce the DBG file. Indeed, HWiNFO relies on that setting.
Yes, seeing the DBG file as 0 bytes during it's locked (HWiNFO running) is normal behavior.

Great. Now HWiNFO is running in debug mode - it doesn't show any noticeable increase in CPU load, and from what I've seen so far I wouldn't expect the DBG file to grow by more than 1 Mb every 24 hours.

Now let's just wait for that mythical and elusive freeze to happen again...

Cheers & thx !

 

[Martin]

OK, let me know Anyway, if you want to speed it up, just perform several cycles of Suspend/Resume and the issue should occur sooner.