ViroMan, on 17 February 2013 - 01:53 AM, said:
I am not sure how to read the MS error reports that are generated. I will have to find a tool for that.
Have you tried starting up sweeper? Does that come up? Its relevant since it uses some of the same things. How about AutoPatcher
itself, AP uses even more of the same things then sweeper does (they have 50~% same code even).
Thanks for the reply Viroman.
Yes, since it was so long ago in the thread
, probably missed that I mentioned in the first post that apup.exe runs flawlessly (and did as well before the autopatcher problem started). Starts up, obtains the update lists on demand, maintains selections, downloads things properly and verifies the MD5 hashes of them all without a problem.
Just checked now, Sweeper.exe (v220.127.116.11) also works without issues. Starts up on double-click, shows text in the log window, ends with "Done".
Those "BEX..." error reports I posted before are saved in Windows 7 as "Report.wer
" files in the folders \Users\(user name)\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_(crashing prog name & decimal code)\.
For posting the complete text (as opposed to just the abbreviated text out of the pop-up frame), I used the AppCrashView program from Nirsoft. As to interpreting the data (that cryptic "Additional Information", etc.), I haven't looked into it, sorry.
_def_x_, on 16 February 2013 - 05:35 AM, said:
Sux Genore you're still having problems with AutoPatcher. You had mentioned that both 5.6 and 5.7 are crashing, so it's not a dll issue.
Sorry if I missed it but have you checked your security tools lately, maybe a firewall or DEP is blocking the exe from running? I know you mentioned the program has run in the past but an update or something could have reset a setting or 2.
I would check DEP first.
You need to get some Windows 7 experience
. Sorry if you missed, but I'm a very experienced, knowledgable user. I never have firewall issues.
As to "disabling error reporting", its a completely different animal in 7 than it is in XP. I used to go into group policy in XP Pro as well and totally disable it. In 7, doing so creates issues.
Disabling the option to send error reports to MS not only removes the first clickable button-line from the screenshot I posted
(not an issue), but it also removes the drop-down box showing the abbreviated text out of the WEP files. Not handy when you want to know exactly is going on with a crash.
Disabling error reporting completely means you don't even get a pop-up frame (as shown in the prior screenshot again) when you have a full application crash. Instead, nothing happens in the GUI. Unlike XP, where disabling error reporting there instead lets you see application specific error frames and the like.
App specific frames like that still appear occasionally in Windows 7 if you are, say, missing a dependency a progam needs at startup. But any GUI details of a full application crash only appear in front of you with error reporting turned on. Unlike XP.
As to what's causing the crashing, it certainly could be a DLL issue. Especially when dealing with VB components; anything missing that another one needs (particularly third-party ones) means trouble. If there is another file(s) that, for example, ssubtmr6.dll needs to work but wasn't installed with Apup and isn't installed or registered on this system. Despite not seeing any missing files after loading that dll in Dependency Walker and nothing unusual showing as missing when profiling autopatcher.exe.
Following that thought, I searched the web for any secondary files that damn ssubtmr6.dll might like to have around. Sure enough, found "vbalIml6.ocx". Made by the author(s) of ssubtmr6.dll; some say its a dependency of it, others not. I downloaded, registered & rebooted, nothing changed.
Finally, DEP. I dismissed it out of hand on first seeing your suggestion as:
1) I had it manually set to "Turn on DEP for all programs and services except those I select
..." with nothing manually selected (with hardware DEP). Always ran it like that in XP when a service pack added it as well. Autopatcher ran fine like that before the problem started.
2) Score and scores (and scores) of Windows programs old (mid-90's) & new installed, tried out and tested, I have yet to run accross anything but a virus that won't run successfully with DEP enabled for all. Of course, legitimate software that can't handle DEP properly is likely out there...but I haven't come across any yet
Not being one to give up the fight, this time I manually added an exception for autopatcher.exe (18.104.22.168). Guess what? It started up without issue after that. It also showed a list of previous things I downloaded (into its directory) with Apup. Didn't go further. So your thought was correct, sir
So I guess the moral to this story: the autopatcher (and/or third party VB file) code needs changing to not violate DEP when its active for all programs on a (Windows 7 32-bit) machine
Edited by Genore, 17 February 2013 - 05:52 AM.