IVAN, there is a comparison matrix on the page:

https://www.hdsentinel.com/store.php

I haven't used Win 98 for years. There maybe a compatibility mode available when your right-click on the shortcut.

Stewart, what firewall is active on that computer? Have you installed a a third party enhancment to windows firewall like the free TinyWall for example as it re-writes the windows firewall rules to block any new exectuables access to the network until specificaly instructed by the user to permit internet access. I mention TinyWall specifically as that windows firewall enhancements developer beliberately designed it to NEVER produce an alert that a program is trying to access the internet and just silently blocks it and you'd only ever find out that it needed the internet by the program being run reporting an error like you reported. I know this from direct experience and eventually removed TinyWall because I got fed up with having to diagnose program failures which kept on turning out to the programs being siently denied internet access.

That sounds like an internet problem - "failed to connect"

S. Pupp, Agree with you. The program warned me about an external HD. It was down to 42%. I immediately made a backup. 3 days later it stopped working. Saved me a lot of jobs.

S. Pupp, The giveaway licensed edition also has email settings too and shows no indication that any of it is disabled in the standard edition license.

See https://www.hdsentinel.com/hard_disk_sentinel.php?page=features

"Alerts
Hard Disk Sentinel has wide range of alerts upon different problems. It can send e-mail (with e-mail->SMS gateway it can be SMS warning to your mobile), network message, can play sound alerts and so.There is an option to send daily emails about current status."

Saved more than one of my drives too!

TK, For amusement only. See my comment no. 14/

Zen , Thanks I suspected as much... you can also use innoextractor to extract the contents of most inno installers which their downloadable installer is one. Then copy the entire extracted contents to the windows 98 machine and try running the HDSentinel.exe trial executable under windows 98 just to be sure it was not a problem with the setup program itself... Though from my examination of the programs executables they are configured to need at least Windows NT 4.0 to have a chance of running which excludes all the non-NT versions of windows.

Alexa, I am perfectly aware of everything you say, as i have been using software from your site for years, normally without issue. However today, this is not working. I stand by what i said earlier.
It is not the latest version anyway, so i will leave it. Thanks

frank, where does it say that I said it's a waste of time ? I was merely stating fact . And who says the Pope is infallible ?

frank, It wasn't Mark, it was me that said it was a waste of time.....credit where it's due!!

Mark Campbell, I'd say only cult members claim or are conditioned to think their human leader is infalible.

Mark Campbell, You have to read here: https://www.hdsentinel.com/rev_previous_versions.php

frank, is that the only thing you know of Hungary, how sad... Well now you know that have a software devleoper or two too :-)

frank, Then it's time to expand your knowledge!

https://hu.wikipedia.org/wiki/Kateg%C3%B3ria:Magyar_feltal%C3%A1l%C3%B3k

Clinton,

"... I mostly use it to see my drive temps in storage tray. If you own a M.2 drive something like this can be very handy."

FWIW... While it won't work for drives connected via USB, I find CPUID HWMonitor handier since it shows some system data as well. I've also used its drive tests on occasion & found them useful.

mike, are you sure CPUID HWMonitor won't work for drives connected via USB? I have it installed on Windows 10 laptop and it's showing the model name and Temperatures and space utilization for the drives when they are connected with one of two different Chinese cheap SSD drives in an old USB 2.0 caddy and the program apparently made all the same discoveries about those USB connected drives and the internal Sandisk SSD drive. Maybe your USB caddy uses a different bridging protocol? This older one uses "USB Mass Storage Device" as opposed to the newer UASP bridging devices.

Jermin,

"... it is not easy task to disable Windows Defender on Windows 10. There is no more option to turn it off on settings. Windows 10 Pro users can use "gpedit" to disable it."

windowscentral[.]com/how-permanently-disable-windows-defender-windows-10

FWIW also check the running processes when Defender's turned off. It's been quite a while, but when I checked win10 ran another, lighter weight Windows security app/process instead. That's one of the things that prompted me to install 3rd party security software that could be turned on/off, but that solution won't work today with 1903 -- Defender will turn itself off when you have other security software installed, but now it will turn back on if that software is either not running or has not been updated.

David J Wilson, It does make a significant logical mistake with SSD drives in a USB caddy... it wrongly lists the drive as supporting TRIM and all the other attributes of TRIM and claims that the Operating System supports TRIM and it's enabled... All are individually true BUT because its in a USB caddy there is no passthrough for the ATA TRIM command that Windows knows to do on any ATA interface. It also fails if a UASP bridging USB chipset is used as they do not have the inteligence to translate the SCSI Deallocate command, which is SCSI equivilent of ATA TRIM command, into the often manufacturer specific TRIM commands... different SSD manufacturers have different requirements to impliment the TRIM protocol and windows has to ask the drives how many sectors can be TRIMed at one time and what size the physical sectors are etc. Simple but accurate rule of thumb if an SSD drive is in a USB caddy of any kind unless the manufacturer can prove otherwise TRIM will never be applied to that SSD while it is in the USB caddy. The same should be true under linux too as the USB-SATA bridging chipsets non-upgradable firmware has no way to know what to do with it.

Kjell, though all the anti-virus programs operate on the basis of data that they have collected from constant research over a period of time, that data need not be comprehensive. since thousands of programs (from all types of resources/sources) flood the software domain every day. In order to be effective and used extensively, the a-v programs adopt the principle of "guilty unless proved innocent" and that is the reason you get the warnings from those programs. The a-v programs themselves call these "false positives" .......... From whatever I have experienced, the downloads have not been prevented, but the installations have been. One method that I have used is to disable the a-v programs for 10 mins, download and install and re-enable the a-v. The a-v programs themselves have this feature of limited time non-deployment.... Your method of using the software only from the trusted sources is the best, but others are not that dangerous ....

Kjell, most software of this type has to hook into the operating system to function correctly. Malware does the same thing and if it manages to do so than it becomes a lot harder to detect and remove. For this reason several anti-malware programs absolutely reject virtually any program that attempt to do this regardless of reason. In generally it's not a good idea to do this but there is still options to see if it's safe beforehand.

You can always download said program to your computer (with anti-malware software running) than upload the program to virus total to see what they thing about it. Odds are if virus total says the software is clean than it is some antiviruses used can false positive a legitimate program from time to time tho. As long as you do not attempt to run an infected application it really doesn't offer much risk sitting on the drive.

It's only when the program has been launched (at least once) can it do any damage to the system short of a OS exploit where it can auto launch itself (or part of it) and pin itself into the bootloader so it launched on next reboot. This is extremely unlikely even for 99% of malware out there.

Kjell,

"I don’t like at all to disable the anti-virus program, though it has been necessary if you should download software from GOTD, and I don’t know why. Can someone tell me?"

1st, it Is Not Always necessary to turn off security software -- I've only had a problem with Defender once or twice, Never had a problem with McAfee, Never with Security Essentials in my win7 VMs, with BitDefender only rarely, & Never with the free version of Kaspersky I ran in a VM for a year. I run the free version of AVG in my XP Pro VM, and I have to turn off real time scanning there to install a GOTD in the wrapper, not because it won't work, but because it slows things down Far Too Much.

Why does some security software object? The methods employed by the GOTD wrapper are also employed by some malware. Windows itself, and all consumer security software make compromises for the sake of usability -- the better your security apparatus, the more inconvenient it is. Some security software presumably doesn't want to compromise when it comes to the GOTD wrapper. And the developers of some security software are no doubt too lazy to try to write code to try to tell the difference between the GOTD wrapper & malware. Then there's also Virus Total... many [most?] security software companies automatically add detection for any new malware uploaded to that database, because you always want the latest protection ASAP, and they only check out those new additions later on. I *think* that's why software like BitDefender occasionally will block the GOTD wrapper, but then will return to normal a day or so later.

Clinton,

" As long as you do not attempt to run an infected application it really doesn't offer much risk sitting on the drive."

I'd politely add: *Usually*. There have been cases where malware code runs because of the way Windows itself will look at or examine certain types of files, e.g. .zip files or images. They even figured out how to successfully run malware from emails that Did Not require those emails to be opened.

"... short of a OS exploit where it can auto launch itself (or part of it) and pin itself into the bootloader so it launched on next reboot. This is extremely unlikely even for 99% of malware out there."

Yes, it's less likely today, but not because it's difficult, but because there's so much low hanging fruit that many cybercriminals & would-be cybercriminals don't feel that they have to bother. There are actually more ways than ever before to ensure persistence [as it's called]. The latest frontier so-to-speak seems to be the sort of mini OS used by UEFI BIOS -- they found an early-on example of UEFI malware in the wild a while back, and they've likely only gotten better at it since.

Be Careful Out There.

Clinton,
>"short of a OS exploit where it can auto launch itself (or part of it)"

It is impossible for any program to auto launch itself; programs cannot think or make decisions on their own. That occurs only after they are loaded into a running state. The CPU then processes the steps in the program, which could then do lots of good or bad things. The main point is that a program has to be started by some other running program or the (already running) operating system.

I purchased the HDD Sentinel program several years ago. I am not aware of it hooking itself into the operating system in a manner that it cannot be uninstalled.

Kjell,

>"I don’t like at all to disable the anti-virus program, though it has been necessary if you should download software from GOTD, and I don’t know why. Can someone tell me?"

It isn't GOTD's fault. I have never had to disable my anti-virus program to install any program from GOTD, and I have successfully installed hundreds over the years. Some anti-virus software will view the setup used for most GOTD offers and block it. Most anti-virus software also have a method to allow programs you specify as safe, but very few people ever bother to go and make the change. Over the years, the same question you have asked has been asked by others. After learning they can alter their anti-virus settings, they have not had any more problems. Take a look and see if that will help you.

Kjell, from my own research and not the Public relations claims that antivrus program for some unexplained reasons get accused of detecting the themidia wrapper as malware false positive and some alledge its because some malware writers protect thir code using themidia.... well none of that is the truth as whenever anti-virus or anti-malware detect anything flasely or correctly it ALWAYS tells you in a popup notification to prove to you it's earning the money and resources it costs... They NEVER block something without celebrating it! What is really going on is the Themidia protection code used to report that it detected debugging software on the system and rrefuse to decode and launch the encrypted wrapped installer... often it would fire up when no real debugger was active. At some point GAOTD developer turned down the sensitivity of the debugger detection routines and the problem apeared to go away... but then a new problem started the themidia code detected certain anti virus heuristics scanners virtualised sandbox as a reverse engineering attempt and since the alert message about the detected debugging program had been removed the Themidia code itself SILENTLY aborts the decoding and launching of the wrapped installer and skips ahead to the Succefully Activated form and that's what gets displayed.

By preventing the Antimalware from doing its Heuristics sandboxing of setup.exe the Themidia code then permits the ecrypted wrapped installer to be decrypted and unwrapped and executed. Of course I could be wrong since I am not the GAOTD developer used to produce the latest build of the wrapper but that explanation is the ONLY one that fits all the observed symptoms and history of the setup.exe/gcd wrapper.

My personal opinion is GAOTD should wake up their developer and re-instate the capture of the Themidia detection of an unacceptable investigation environment and properly flag an error and change the final message so it does not lie and say it had been succesfully activated when the program knows damn well it aborted the decryption and launching of the installer and the anti-virus/anti-malware programs did NOTHING to prevent or quarantine any part of the wrappers operation! And stop blaming every other AV vendor/developer for their own use of Themidia in an incorrect way.

krypteller, have you never noticed that at no point do any of these blamed anti-virus programs EVER report they detected somthing suspicious... because THEY NEVER DO! It's NEVER the AV program blocking the Themidia code! It is the Themidia code silently aborting because it did not like the AV programs environment investigating what it was doing.... That's what Themidia code does! The encryption of the installer predates the use of Themidia. Themidia was used as a software counter measure to a simple hack that was published on youtube I think that showed everyone how to find the we*.tmp file that the original wrapper used to write to the temp folder and then launch some of us spotted it and used it to get a personal copy of the unprotected installer but some idiot decided to make the knowledge public so GAOTD had to up their protection to maintain their business model.

Gary, not strictly true there have been and will be many cases of remote code execution vulnerbilities including some that were designed in like the .WMF remote code exectuion vulnerability... https://www.grc.com/wmf/wmf.htm or the more modern ones scattered around various parts of Microsofts programs usually described as such and such component improperly handles data in memory which can lead to a remote code execution vulnerability....this update corrects that behaviour.... it is well known to be a designed in family of vulnerabilites that exists in many places in windows and can easily be fixed and moved to a different area of windows if exposed or threatened to be exposed publicly, because the error is in DATA processing and yet Data Execution Prevention protection NEVER blocks the remote code injected via specially crafted DATA and executed.

krypteller, any solution that takes away from the process the virtual environment that the Themidia code detects as invasive and to investigative allows the Themidia code to permit the retrieval of the decryption key and decryption and spawning of the in RAM image of the installer. Yours does this by instructing the AV program to not inspect any processes launched from the ignored folder. Other methods such as disabling the anti-malware program or disabling heuristics would have same effect. Your method is least risky of the methods often being used :-)

Same end result just the much vaunted reason that has been propgated was incorrect and blamed innocent anti-malware developers software.

There is also an option in windows 10 that I cannot remember if it is enabled by default or not and that is ransomware protection. It was added in one of the feature updates. I am not sure which one as I skipped a couple and if it is enabled then there is a very strong probability that it will prevent the giveaway wrapper from working, likely the problem that causes a report of a corrupted installer rather than the silently skipping the launching of the installer and landing on the successfully activated window.

It is possible that your method may mitigate with that too, though I'd hope not as ransomware malware could simply enumerate the windows 10 file system for any writable folder ignored by Windows Defender and then deposit itself in that folder and relaunch itself from there and proceed to encrypt user documents and hold the data to ransom.

TK,
>"Gary, not strictly true there have been and will be many cases of remote code execution vulnerbilities including some that were designed in like the .WMF remote code exectuion vulnerability"

Yes, other than the user initiating a program to execute (via the OS, scheduler, or anything that causes the file to be processed by the CPU), there have been many different types of initiating a program to execute, from the early days of DOS and ASCII BOMBs (sending a text file to the screen could cause a program to start) to the e-mail attachment vulnerabilities we had just a few years ago (assessing (not accessing) the attachment could cause a vulnerability). Executables have been hidden in all types of files, and then a method was used to start the executable part (e.g., an image viewer displaying a photo, and the processing of displaying the photo triggers something being loaded into executable memory). Those sort of vulnerabilities get solved pretty quickly.

Steve Gibson's coverage of the Microsoft MICE issue was big news back in 2010 (I think)(before Vista). I have not found any machines in a long time that originally had it because any that did have all probably been patched. Later machines didn't have it because it was removed by Microsoft. Even the MICE issue required something else processing the meta file before it caused an execution.

The main point is that regardless of what type of file (standard executable/hidden/disguised. etc.) it is merely taking up space on disk (non active), and cannot start itself. Something else has to trigger the action that causes that file to be processed in some manner before it will execute or cause something else to execute.

Gary, ok I thought that that example would have been sufficient but you need another? SMB v1 vulnerability that was exploited by wannacry ransomware to infect any windows NT based computer that was connected the the windows network that had SMB v1 server running that was left there for NSA to gain unsolicited remote access to computers of interest I believe the NSA exploit was known as eternal blue. The attackers code did not have to be ON the target machines hardware and since the SMB v1 server is a service it is always running on any machine with SMB v1 enabled which was practically all the machines on the UK NHS distributed LAN... and there are similar non-disclosed no user help required vulnerabilites in Windows 10 and back that will only ever be patched if a 3rd party security hacker or criminal hacker discovers any of them and makes it known by either proof of concept or a zero day attack. A similar vulnerability existed in XP I forget if it was connected direct to the internet and there were bots continuosly scanning the internet IP spaces sending a malicious packet that if it found an XP machine connected to the internet via a modem without a firewall it would cause the target machine to shut down. Remote code execution vulnerabilites can exist in any network facing server on a windows machine which is why windows firewall was first created and integrated into an XP service pack. But on a LAN for you to use cerain facilites, certain servers have to be passed through any firewall if the features are to be used and accordingly any vulnerabilities in those servers that permit remote code execution DO NOT require something to launch the payload as the vulnerable server is always running and the malicious software knows how to exploit the vulnerability and worm its way around a LAN from one vulnerable machine to another with NO operator intervention. It can even happen via a remote user that dials in via a VPN on an infected machine that got infected elsewhere and if that VPN is given direct access the real LAN the entire companies machines could get infected too! So once again what you are claiming is not true in all circumstances.

TK,
You are pointing out more possibilities of vulnerabilities, and the ones you mention only skim the surface of what types of exploits that have been developed, ... but my initial comment has nothing to do with those possible vulnerabilities. I was responding to part of the comment made by Clinton, which contained the text:

>"short of a OS exploit where it can auto launch itself (or part of it)"

That part I quoted at the start of my comment. Had I thought of it, I would have shortened my quoted text back to him to:
>"... where it can auto launch itself ..."

The only part of that comment I was responding to is the part about a program/exploit auto launching itself. Nothing on the computer can auto launch itself, not even the OS. It needs the BIOS to initiate the OS. The BIOS needs the circuitry/logic to start it when power is applied.

Clinton's comment just above that line I quoted said essentially the same thing: "As long as you do not attempt to run an infected application it really doesn't offer much risk sitting on the drive."

The part of a program "auto loading itself" is what I wanted to clarify. That part of the comment seemed to contradict the statement he had just made. I think if Clinton thought about it, the sentence would be worded slightly different. Anyone that knows very much about how a computer works (and obviously Clinton does) knows that executable code has to started by something that is already executing, whether it be initiated by the user telling the OS to start it, a scheduler that the OS runs that will start it, or a remote execution that starts it. The main point is that it cannot start itself; some already executing code must initiate it. I am pretty sure that is what Clinton was intending to point out as well. It just seemed odd to use the "auto load itself" part. It makes it sound like a file could somehow spontaneously start itself. For anyone that might have thought that was possible, I just wanted to make that part clear.

Gary, What I am describing is a program running on a different machine auto loading itself onto another machine that is running an operating system and that type of program is traditionally called a WORM

https://en.wikipedia.org/wiki/Computer_worm

as oppsed to a virus or trojan which is what you are describing. virii and trojans do not traditionally start themselves as you say but BIOS does autostart as soon as power is applied which then loads the operating system and startup programs and any malware that has installed itself in a prior session into the startup sequence by also having viral properties or rootkit properties. But by including live WORM code functionality it can once autostarted (because that's what it programed the operating system to do in the previous session) then install itself and launch itself on other connected vulnerable computers. So in previous session the WORM procedure on the other machine installed itself and its payload on the target machine without user interaction or scheduler interaction and then configured the target machine to launch the worm and payload on next operating system restart so yes the program started itself intially on the target machine, and then programmed the operating system to re-start it on next operating system re-boot so this class of malware does infect new machines and start its code executing and manipulates the startup processes to restart itself on reboot so as I said... what you were claiming was not strictly true in all cases.
Pretending that you werent saying that programs cannot start themselves on a victims computer is only just talking about the fact that computers are complex machinisms and all interconected kind makes your reply absolutely pointless since if you don't switch a computer on to prevent your WORM infected computer from loading and running the BIOS and that loading and running the boot sector code which then loads and runs the boot manager which then loads and runs the oeprating system and all the configured services, drivers and programs including the WORM self installed program with its self programmed auto run. because without the user switching it on in the first place the user just has an expensive paper weight or door stop. But if they use it as a computer the WORM based malware has installed itself and started itself on that computer. In fact there are several tricks that have been used to allow a program to auto-start itself like there was the %PATH% exploit where a worm would save a copy of itself as an executable that is normally launched as part of windows boot up period but the default launch did not explicitly state the path to the file but relied upon the systems searching of the %PATH% system variable list of paths and the worms saved payload would then autostart in place of the same named and correctly located executable... So it is wrong to claim that programs cannot start themselves because certain classes of programs certainly can! Some can't but SOME most certainly can start themselves without any intentional action or consent of the computer operator on the victims machine.