Glenn9999

Where might one obtain this program? I get the feeling that checking its output against a known good SHA-1 generator will reveal this "Hash" program to be in error, if you are getting the values right out of the security catalogs.

When I was reading things trying to solve my other problem, I did read reports of people cleaning cable plugs and drive sockets (for lack of a better term). Basically, as it was described, it reminded me a lot of the old Nintendo cartridges and the cleaning kits that they sold for those for the connection problems there. I also noticed myself how "unstable" the plugs are (short description of what was wrong with my "other problem"). It's always good practice anyway to reseat any cables if you run into problems, and check for dirt in them, and if worse comes to worse, rubbing alcohol on a cotton swab followed up by pressurized air to make sure it's dry and the cotton is gone.

Went ahead and wiped the OS and the problem went away. So I would say either a driver conflict in me trying to update them, or I ended up with a virus somehow (though Microsoft Defender and Malwarebytes Anti-Malware both missed it, if that was the case). Had the 32-bit OS on long enough to see the problem gone, but since I had the new processor and enough memory to do it (the original issue as to why I went back to 32-bit), I went to the x64 version and hopefully can stick with it.

Version 2.02 is released and can be found on the first post. 2.01 - changed patch listing routine so they would be listed in order from oldest date to newest date. This should aid the proper installation of patches if it becomes an issue. 2.02 - I fixed it so it would work in patching my Windows 8.1 x64. It worked, and hopefully it will still work in other things. Please let me know if it doesn't, if you try it and run into problems.

Actually I think it was the optical drive. Higher pitched grinding than if it were a fan. It completely ceased when I reboot. The more I think about it and research it, the more I think that a parallel issue to the Intel IRST stuff that Tripedacus suggsted is happening. But I'm not really seeing any suggested solves. Updated the BIOS again on the motherboard, flashed the SSD. Threw another set of drivers on there. Maybe I'll come across one thing that will solve it.

BSOD now. KERNEL_DATA_INPAGE_ERROR, accompanied with a grinding noise.

As stated up above, this board does not have such settings. The closest smelling thing is "EPU power saving mode", which doesn't seem indicative of anything related to sleep modes.

I reverted the chipset drivers to what was on the disk, but I got the drive being sanded and taking a minute to come back. Or the system gets so unstable I have to hard-reset it. Part of the reason why I tried updating the drivers was this symptom. The RAID thing is a possibility, as I'm not sure if there was a specific port that non-RAID drives needed to go in (3 on the front, 3 on the side). This is because I get the same problem if I try using the optical drive. Drives are set to AHCI in BIOS. I'm not sure how Intel software has anything to do with an AMD board/chip. The BIOS does not have a "Resume" setting that I can find. Only thing left I can think of is that I found a bios update dated 12/14/2014, so I might fire that up and see if things get better that way. Edit: Still unstable.

Okay, this computer just died while I was using it. No keyboard or mouse input possible. Hard reset the thing and got the BIOS message. Cut the power, now I'm back up again. For now.

Asus A58M-E and Kingston SV300S37A120G. Obviously (on the first sentence), which is why I'm looking in that direction. The problem didn't exist with this drive in the old board. Just putting it in sleep mode manually is fine. Since it didn't exist with the old board (it got replaced for a couple of capacitors blowing), I'm wondering if the drive got compromised then, as well. Of course, I wouldn't put it past being a Windows problem either (namely drivers with the specific function of putting this drive into sleep mode), as I've noticed recently it has been unstable on this machine with time.

I have a machine where I just replaced the motherboard, CPU, and memory in it. It's been working fine, except lately when I walk off from the computer for an extended period of time. When I come back, I see a BIOS message about providing a boot device, etc. If I completely cut power to the computer for a few moments and then turn it back on, it starts working again. My guess is with the board / drivers that are on this computer now (I reloaded Windows 8.1 with all the new drivers on it) that somehow it's not handling sleep mode well with the SSD, so when it cuts power it's not getting it back? Or is there something with the BIOS going on? Or is this indicating that I need to worry about this drive and replace it?

Okay, let's see if I can remember it all. Like I mentioned before, Windows exposes certain APIs to programs designed to run under the Desktop. Some of those are your File Manager functions. Basically, it calls the API with the files and the action is accomplished. This is what the Windows developer sees and what File Manager calls. Behind those API calls are your linkages to DOS. The main purpose of DOS is to expose certain hardware functions, along with some basic OS functions. This is done via interrupts. Most high-level DOS compilers have similar API functions to the Windows ones to do certain functions like copy or delete files, so nine times out of ten the programmer doesn't see these unless specifically desired. But behind those is the interrupt calls. There's a huge list of those, to the point that you can fill a floppy disk or two with it and accompanying documentation (not big now, but big back then). In ASM and low-level you'd have to call these to get anything done - put text on the screen, load programs to run, read input from the keyboard, turn pixels on and off on the monitor, read from memory. Basically put: Everything. As I mentioned before, along with hardware functions, DOS has a huge catalog of interrupt functions (specifically INT 21). To copy a file in ASM or low-level, it would involve hitting the proper INT functions in the right order (Access File, Read Buffer, Create File, Write Buffer, etc) to accomplish the copy. As you might imagine by this description, programming is an exercise of taking simple blocks of functions and organizing them to do more complex things. Code the low-level machinations to copy a file into a procedure call. Modularize it. Then use that to process the whole list as presented by file manager, the complexity is increased. This idea exists with everything, including code to draw windows in standardized manners - the main basis behind things such as Windows or DESQview or basically anything you can think of. So to answer your question, File Manager is copying the files by calling a Windows API call which in turn triggers certain DOS interrupt calls. It really isn't File Manager or COMMAND.COM or any other specific file command that's doing the job. But File manager can't function without the API calls exposed by the Windows DLLs, or the Interrupt calls exposed by DOS. (and I realize that certain drivers in Windows might change this model around, but it's a basic sketch of how things worked in the 3.1/9X world)

It's best to think of Windows as a desktop program, more than an OS when it comes to this era. In that sense, Windows itself is just a program that runs on top of DOS. Anything earlier than Windows 95 actually ran this way, where you had to boot DOS and then type "Win" to get the Windows desktop program (of course you could always do this with AUTOEXEC.BAT, but that's neither here nor there). Of course, there were APIs that programs could hook into while Windows was active, and that was what constituted "Windows programs". 95, 98, and ME blurred this line, mainly by hard code booting into the desktop. But DOS was always there in any of these cases, to the point that you could construct a real "DOS" boot disk out of the files that existed in these Windows installs.

FWIW, haven't had any issues with KB3000850 so far after about 24 hours.

Yes, if I recall correctly, you need to install one of the Internet Explorer Updates before the Windows Update site gets non-broken. I can't say which one because I download updates anyway. I just know it doesn't work out of the box, and then starts working after those updates gets applied.

It still reports on my system in Windows Update after I uninstalled it for some reason, and I don't have Visual Studio 2010. I gathered from other searching that it sounded like some kind of run time associated with .NET in general, so perhaps it originally got installed that way. But regardless, I can't say I deliberately installed this before.

It showed up in my normal batch of updates. I guess it's some component that another one of my programs require. The full name of the thing is ASP.NET Model-View-Controller version 4.0 and described as such: "ASP.NET MVC 4 is a framework for building scalable, standards-based web applications using well-established design patterns and the power of ASP.NET and the .NET Framework. It installs side-by-side with ASP.NET MVC 3, so get started using it today!" Since I don't know what would have been put on the system that called for it, I guess I can uninstall it and see what breaks and that would answer my question.

Did anyone else have any issues applying the file for KB2993928 on October 14 (aspnetmvc4-kb2993928.exe)? I kept running the file and got nothing (and the patch still reported on Windows Update). Eventually I downloaded the whole thing (AspNetMVC4.msi) and the patch notation got removed. So is there a standing issue with this patch or is there something wrong with my computer that this didn't work?

Good you have it solved. Looks like that was what it was.

Cross-compatibility windows programming is a pure PITA, simply because Microsoft changes the API around all the time and does an incredibly poor job of documenting those changes. You really have to get the SDK's for every version in order to even have a chance at getting these changes right. Solving this problem will require that you delve into Windows.H and post what the "ofn" structure is. Your results clearly indicate that the "ofn" structure was changed between Windows 95 and 98 to be larger. Once you can find out what the changes were, you can adjust your code accordingly since most of the API changes are designed to be backward compatible (code that works in 95 works on 98). Basically that should mean testing for version (GetVersion/GetVersionEx) and then passing the different structure size. Barring any concrete documentation, I'd start subtracting fields from the end of the structure in relationship to its size and then see when it starts working. But in any event, please post what the "ofn" structure is, so others might see what is going on.

Kind of a merger on this one from the video thread and this one. I found a copy of The Running Man (underappreciated classic of the 80's, watched it three times now in the seven days since I got it) and heard this song at the end by John Parr. He's most famous for St. Elmo's Fire (Man in Motion), but here's the thing that I don't get with most of his known songs. He's probably in the top 3 in that time for being able to do a good high energy rocker typical of the time. But it seems like he never did much beyond the handful of movie soundtracks, and a few one off singles. Anyway, here's the song (forgotten but then remembered after watching the movie again - note the bits of the movie in the video):

You really got to download and store ALL updates that Microsoft produces for that very reason. There's never a guarantee Microsoft will make it easy for you to run their older OSes since they want you hemmoraging cash as repeatedly as possible. That said, there really weren't very many Windows ME patches. Here's the official list: FileName="323172USAM.EXE" Sha1Hash="4D83C11DBC956B4B8097971B0FB661F63C6ED562" FileName="323255_ME.EXE" Sha1Hash="E1DD90C4278177762399BCCF33B4B58D6B193FA5" FileName="329048.EXE" Sha1Hash="91A09CD72AAED57C58C4AF3B5594CD3CF16D13E0" FileName="329115_ME.EXE" Sha1Hash="2AA0214F231C897760684BFF3044AF71CA849392" FileName="812709USAM.EXE" Sha1Hash="1148174010306CC2D82B42DFA8F50BE343FA2DA9" FileName="814078js56men.exe" Sha1Hash="DF03F6B7141C445944C7D981A29297B97636A5A5" FileName="823559USAM.EXE" Sha1Hash="908A13240672687F2F89F34AD0C87F9B18C8514C" FileName="888113USAM.EXE" Sha1Hash="3AF29F957D5E9B46C65DF1CE707EB2C19B07BD10" FileName="europatch.exe" Sha1Hash="86903C68C692AF6ACFD573C556CFDAA197E0C50A" FileName="GDI_873374_ME.exe" Sha1Hash="ED2557BB0905A05A62826AA7D9B62351C4113D1A" FileName="HD Cache 273017.EXE" Sha1Hash="6C715C3EACAD598B787D078EDE2E274E8A3BED3D" FileName="IE Nav Sound Update ME.EXE" Sha1Hash="C781082590FFC701D6E40176C981C9E3FB846AEF" FileName="IE-KB891781-Windows-98-ME-x86-ENU.exe" Sha1Hash="2C7B14CA73FBC1AA5A128964811D656B39367832" FileName="IE6.0sp1-KB833989-x86-ENU.exe" Sha1Hash="B1839CFE7A928F461564224A8BD1E4DE3BFF2AD7" FileName="IE6.0sp1-KB916281-Windows-98-ME-x86-ENU.exe" Sha1Hash="88861152A18BD42F8C3FAF7B4CE7705BBDFDBFC7" FileName="IE6.0sp1-KB918439-Windows-98-ME-x86-ENU.exe" Sha1Hash="B6F9015EEFC808702BAEECE66FB1A9FFC14331AD" FileName="Movie Maker_287564_ME.EXE" Sha1Hash="AF5E0641C80BA89C82472244A58A7031E18E605A" FileName="NDP1.1sp1-KB867460-X86.exe" Sha1Hash="74A5B25D65A70B8ECD6A9C301A0AEA10D8483A23" FileName="NDP1.1sp1-KB886903-X86.exe" Sha1Hash="535F57E5A8ECEAB18533C50C0B0E1469ED45331F" FileName="OE6.0sp1-KB837009-x86-ENU.exe" Sha1Hash="D71A46EF9D139B626355C959D5E7894F65EF9F2F" FileName="OE6.0sp1-KB887797-Windows-NT4sp6a-98-ME-x86-ENU.exe" Sha1Hash="61BD8CB160F70A72BE1369F394409CE37EE439D8" FileName="q329414_mdacall_x86.exe" Sha1Hash="EBA6AED2DCA3DCC344E4BD7606A1632F7C5D7ED6" FileName="Q811630_WINME.EXE" Sha1Hash="483042093272166647BB6B4BFC717D6B8FC1C316" FileName="Share Level Update 273991.EXE" Sha1Hash="A2ECEB89418158950CAED10A98A6928BE08B7BE5" FileName="Sys Restore Update 290700.exe" Sha1Hash="5B292FBAE40E608246B81D37BE512477234336B2" FileName="UPNP 311311.exe" Sha1Hash="6349D7B4DF7641875F34B582A05C3690276CC038" FileName="Windows9X-KB917344-x86-enu.Exe" Sha1Hash="E8F43F0688EE4C1A1426FAB9769BC02ADF6A35A8" FileName="WindowsME-KB891711-v2-ENU.EXE" Sha1Hash="E1FDB4E585970E6B3D49D59A0DBF8AC045E583D9" FileName="WindowsME-KB896358-ENU.EXE" Sha1Hash="E497688C3A3761563661AE30F0AE28B0CCCAFCB3" FileName="WindowsME-KB908519-ENU.EXE" Sha1Hash="F303A00071C9DD7E8B5490CA5E7EEFB03046A24B" FileName="WindowsME-KB918547-ENU.exe" Sha1Hash="746A928FFE15FC9D7FDCB7EA879B39A16E7EEF19" FileName="WindowsME.Windows98SE-KB904706-DX9-x86-ENU.exe" Sha1Hash="53CF577148518D6EF67200D96745D7B028B6666C" FileName="WindowsMedia9-KB828026-Me.EXE" Sha1Hash="2E6A54F839E338944EE5D0477413F5B9A763447D" FileName="WindowsMedia9-KB885492-x86-ENU.exe" Sha1Hash="40FB17E82725ECC09EF65A2355612D4A5DAC2185" FileName="WindowsMedia9-KB911565-Win9x-x86-ENU.exe" Sha1Hash="117204DB161B955949142FA855C19FE1B58ECBAD" FileName="WindowsMedia9-KB917734-Win9x-x86-ENU.exe" Sha1Hash="545109D513743C2D13B728E1938F3B5EE8495F4A" You may or may not find the files, but those are the names (as I have them stored, I might have renamed some of them slightly) and SHA1's of the official updates as offered once upon a time through Windows Update.

jaclaz: It enabled me to see what I needed to see. Thanks for the suggestion.

You provided a response that was ultimately unhelpful because as I stated, I already tried the UI options, which were exactly what you indicated. And as I originally stated, Microsoft has nerfed this section where you can not set command-line options behind programs. You can only set programs. This makes Control Panel - Default Programs and "associate a file type with a program" absolutely useless to me in addressing this problem (what program, what file extension really doesn't matter, it can be extension .bla and the associated program does not open this file correctly). The older Windows OSes let you set these options in the UI. Windows 8 evidently does not. That said, I want to see the command-lines that Explorer is using behind a file association and be able to change them in order to fix this problem of the explorer file association not opening a file properly. How do I do that?

As I stated, I used these UI options to no benefit. The question was to fix a file association, not set one.