46 replies to this topic

[ViroMan]

I am starting to wonder if DependencyWalker is correctly reporting things.

IEShims.dll should be in your "Program Files\Internet Explorer" folder, it's part of the initial install. Even then, the application makes no use of IE so I have no clue why it says you need that DLL file.

Anyways... try the latest version I put up in the post above yours and see if anything is fixed or changed.

huh...

Edited by ViroMan, 12 February 2013 - 03:45 AM.

[_def_x_]

ViroMan said:

...ohh I totally forgot about those. I looked around and found a way to generate proper manifests and include them into the exe's

...anyways... as I said above "When I look up 430 errcodes it tells me that the DLL files should be re-registered.

...I am starting to wonder if DependencyWalker is correctly reporting things.

Put on your todo list for the next APUP - compile w/ manifest.

Yeppers, it appears all files are registered. Is AutoPatcher reliant on a specific version of SSubTmr6.dll, v1.1 versus v2.0, would this cause any problems?

It may not be, it's getting a bit old too I think. Is there a better tool than DW for troubleshooting an exe?

** One change since 5.7.18, the Yikes! error now shows line 108 as the suspect code, might help... see attachment.

** Running - autopatcher.exe /devmode /verbose /nolicense, the /devmode accomplishes the same thing as the RED X trick but you get a nice big Ignore Error button to click, once clicked AutoPatcher fires right up... see attachment.

Genore said:

...I seriously wouldn't try integrating MSJAVA.DLL into the EXE.

...MSJAVA.DLL is long (long) obsolete, a potential security risk and so on.

...No opportunity is given. Windows 7 handles errors completely differently than XP (which I used to use up until recently).

I don't think anyone is, I think DW is simply noticing it's missing on my system, not necessarily that it's needed to run AutoPatcher.

Yes it is obsolete.

I have error reporting turned off, possibly bypassing a step that closes the erring exe file down. If you can you might try running without Windows error reporting. It may be more difficult with Seven, who knows.

** I'll keep an eye on this thread and test & report as needed. I've contacted my friend and he'll be testing AP 5.7.18++ too.

Followup: I've been reading about issues compiling VB6 apps on Windows 7 SP1
... http://support.micro....com/kb/2517589

... http://www.vbforums....l=1#post2628681

... http://blogs.technet...ice-pack-1.aspx

... http://msdn.microsof...v=vs.60%29.aspx

Edited by _def_x_, 12 February 2013 - 07:44 AM.

[ViroMan]

 _def_x_, on 12 February 2013 - 06:34 AM, said:

** One change since 5.7.18, the Yikes! error now shows line 108 as the suspect code, might help... see attachment.

That is the line responsible for activating the auto-resize capability of AP. Its uses Windows API in some spots. It could be the problem. I never touched anything to do with this stuff though so I have no idea why its having issues now. I am not going to dig into it tonight though and end up with nightmares in more then one way... will pick it up tomorrow.

[Black Ghost]

I was trying out the version 5.7.18 and the one thing a saw was everything was in black. It should be black for not installed and blue for installed. Right?

[Whatacrock]

Tested ap ver 5.7.18 on my vista machine and same result as Black Ghost...no items showed as blue, All critical modules were checked and in black..
Same for the rest of the releases I checked in ..
Something is amiss..

Reverted back to an older AP and everything went back to normal.

Edited by Whatacrock, 13 February 2013 - 02:12 PM.

[ViroMan]

Really, strange. Both my XP and win7 show blue items. My win7 is independent of the XP in that it doesn't have VB6 installed(VB6 is installed on XP) so if other people are missing things my win7 should be as well. The fact that people are having problems that I don't have is disconcerting. Everything I modified "should" have NO effect on the rest of the program. I only added debug code to the first 1/4th of the program and moved when a variable is initialized(would cause a crash since in some situations it might not get initialized.)

I will look into it. probably something I kicked around by accident.

[Black Ghost]

I am running Windows 7 when i saw this.

[ViroMan]

BG, try running your AP again but, use /verbose. I always run with verbose but when I ran without verbose it stopped showing blue. I think I tripped something when I was adding verbose code back in.

ahh haha, im dumb. I told it not to run through the commandline checking function if you didn't run AP with a commandline. Well in the commandline check function it switches some things ON if you don't pass a switch to turn things off. One of them being turning detections off. SO detections was always left off unless you ran with any kind of commandline.

This will be fixed in the next release in this thread.

Edited by ViroMan, 14 February 2013 - 01:20 AM.

[ViroMan]

everyone who is crashing(getting the yikes window)....
can you check your bin and windows\system32 dir for SSubTmr6.dll and check its version by right clicking on them. You SHOULD have version 2.0

edit:
after some testing I can replicate your error exactly if I use the older version of that DLL file. Attached is the DLL file. It seems that AP is unable/unwilling to overwrite a DLL file once it has been copied to windows already. I will do some poking around but until then... here is the DLL. For x86 systems ... place it in system32. For x64 systems place it in your SysWOW64 dir also place it in your /bin dir in apup

Attached Files

•  SSubTmr6.zip   14.17K   63 downloads

Edited by ViroMan, 15 February 2013 - 03:32 AM.

[_def_x_]

_def_x_, on 12 February 2013 - 06:34 AM, said:

Yeppers, it appears all files are registered. Is AutoPatcher reliant on a specific version of SSubTmr6.dll, v1.1 versus v2.0, would this cause any problems?

ViroMan, on 15 February 2013 - 02:51 AM, said:

after some testing I can replicate your error exactly if I use the older version of that DLL file.

I put 2.0 in the AutoPatcher zip script way back when, it may have been overlooked at some point and 1.1 is downloading again. Anyway, all my archives have ssubtmr6.dll in \bin, I'm sure I dropped it in manually.

This is what might happen on some systems, it appears to have happened on mine and my friends.

In my case, another application was periodically re-registering ssubtmr6.dll 1.1, I think it was Malwarebytes, this is the only other app that uses this dll but it stores it in another location, not \system32. Malwarebytes may be able to do this, not sure, but the app does run as admin so it is feasable it could over-ride a previous change made to ssubtmr6.dll. I recently upgraded, complete uninstall (old) and install (new) - might have happened here.

What can also happen is if you register or update a .dll as a user, the change is not system-wide, it's stored in HKCU (current user), not HKLM (local machine). This is what I believe was happening on my friends system. He shares a system with a few others, he has been making changes as user - not admin.

Upgrading and registering ssubtmr6.dll 2.0 fixed our issues. You'll want to properly un-register 1.1, and register 2.0 - as an admin so the changes stick.

[Genore]

Unfortunately, that's not the issue here.

There is a single user on this system--myself as admin. There is a single version of ssubtmr6.dll on this system: file version 2.0.0.0 installed with autopatcher/apup, the same thing as in the ssubtmr6.zip download from ViroMan. I unregistered and reregistered that (old, pre-Windows 7, third-party) ssubtmr6.dll v2.0.0.0 in \Windows\System32. There is no change in the crash behavior (noted in my first post in this thread and every subsequent one) of autopatcher.exe 5.7.0.18.

Here's still hoping for an updated autopatcher.exe that works properly. No other application on this system behaves like this (and I have a boatload; only autopatcher.exe uses that dll, though).

[ViroMan]

_def_x_, on 15 February 2013 - 04:50 PM, said:

You'll want to properly un-register 1.1, and register 2.0 - as an admin so the changes stick.

The funny thing is, as I said AP code tries to register that DLL file each time it starts. It doesn't seem to work though when its already registered(even though from what I read it should always work). I will have to change the code to verify versions and add a 2 lines to un-register existing files if they are not the same.

[DesertJerry]

Had the Yikes problem on my #2 system's XP Pro - downloaded the zip file and put the dll in \system32 - problem solved. Odd thing was the XP Prox64 and Win7 Pro 64bit on that system worked ok.

[_def_x_]

ViroMan, on 16 February 2013 - 03:29 AM, said:

The funny thing is, as I said AP code tries to register that DLL file each time it starts. It doesn't seem to work though when its already registered(even though from what I read it should always work). I will have to change the code to verify versions and add a 2 lines to un-register existing files if they are not the same.

Yeah, I can't be exactly sure what caused my situation, AutoPatcher had been unused for some time, I'm not sure what other app was bothering this dll, I figured ssubtmr6 was mostly dorment, it surprised me when I noticed MBAM registered 1.1.

My system might have been getting confused, launching AP 5.6 - 5.7.5 - 5.7.15, then 5.7.18, and back again. If 5.6 looks for 1.1 and 5.7 wants 2.0, YIKES! is right.

I wanted to ask, you mentioned somewhere a /fast switch I believe, checking only size or hash, was this an AP or APUP switch, or am I mistaken altogether?

Edited by _def_x_, 16 February 2013 - 04:22 AM.

[Genore]

ViroMan, on 16 February 2013 - 03:29 AM, said:

I will have to change the code to verify versions and add a 2 lines to un-register existing files if they are not the same.

This is drifiting into fixing something unrelated to the original issue here.

Are you looking into the original fail issue with v2.0 only on the system on Windows 7 32-bit and fixing that?

[_def_x_]

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.

[ViroMan]

Genore,
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).



Def_X

There is a fast switch for both Sweeper and AutoPatcher. It disables hash checking and they rely on size checks only. Much-Much faster while still being somewhat sure its what it is supposed to be.

Also... its possible that I might have given you guys the old DLL by accident. I sometimes compile things from the original code when I start a new branch of code and I copy things from it. I try to make sure this doesn't happen but, it has happened once before.

Edited by ViroMan, 17 February 2013 - 01:59 AM.

[_def_x_]

 ViroMan, on 17 February 2013 - 01:53 AM, said:

There is a fast switch for both Sweeper and AutoPatcher. It disables hash checking and they rely on size checks only. Much-Much faster while still being somewhat sure its what it is supposed to be.

Thanks, I'll start using /fast to see how it performs.

You know, this brings up what might be a nice option for AP, /hash (verifies hash only), /size (verifies size only), running without either checks both hash and size - just a thought.

[Genore]

 ViroMan, on 17 February 2013 - 01:53 AM, said:

Genore,
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 (v1.2.0.6) 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 (5.7.0.18). 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.

[_def_x_]

Genore said:

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",

blah blah blah ...
blah blah ...
blah ...

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 .

No, the moral of the story is you, rather your over-estimated skill set along with an obnoxious posting style. It's not me, it's not AutoPatcher, it's you. You overlooked a very obvious possibility, and we assumed you had exhausted them.

Your last post should have simply said - "it was DEP on my system, made an exception for said exe, it's all fixed now. Thanks for the help." Instead, you bury your mistake by focusing on bad code, anothers' lack of this or that - you missed it and you're right in front of it, remember, you're the Windows 7 expert.

I don't know why you didn't say thank you and leave it at that, instead you lecture like a disapproving parent.

As well, it is completely safe to disable WER while trying to identify a problem. It obviously didn't help you now did it. You don't know what your talking about here, this is tech-101.

As far as the applications and their interaction with the OS, it's been noted for a while and code will eventually be emplemented, but don't forget everything done here is donated time - free of charge. If something here doesn't meet with your approval, my suggestion is to use WU/MU, WUD, Offline-Update...