46 replies to this topic

[Genore]

_def_x_, on 17 February 2013 - 10:36 AM, said:

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.

Bleh. It was found to be Autopatcher. And I should not respond to unnecessary arbitrary personal attacks, but I'll do so for what is likely my last post here. You apprently overlooked the So your thought was correct, sir, intended to be a compliment.

Sorry, but enabling a DEP exception for a modern program simply isn't very obvious. Especially when such a problem is far more rare than other possibilities here. Also, hardware DEP normally works by providing its own error/warning frame when it catches incorrect memory accesses, etc.. As opposed to program crashes or whatever else interfering with providing that frame. I would qualify that by restating my experience with all sorts of programs old & new not exibiting such an issue (besides virii), thus a DEP exception not being the first troubleshooting step on the top of mind. But such statements apparently bother you, so I won't.

_def_x_, on 17 February 2013 - 10:36 AM, said:

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.

OK dude. I was posting as I went along with troubleshooting. You made mention earlier of not having experience with Windows 7's WEP as opposed to XP's so I spent time detailing the output differences. Sorry about spending time doing so.

_def_x_, on 17 February 2013 - 10:36 AM, said:

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.

Huh? Where do you get the idea that I didn't? With it disabled, as mentioned, full program crashes nearly always provide no UI feedback at all in Windows 7, unlike XP. Including autopatcher when tested with the problem with it disabled, thus providing nothing of value. Who said it "wasn't safe"? And what are you talking about in that "I don't know what I'm talking about"?

_def_x_, on 17 February 2013 - 10:36 AM, said:

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...

I prefer the MS Download Center .

My "approval" is irrelevant. It was found in the end to be an issue with autopatcher unusually not working with DEP. That's all. The managers can take the problem info and do what they wish with it. It doesn't matter to me at all. Its a great program idea and I do really appreciate Viroman's help with the matter.

Good luck.

[ViroMan]

both of you need to calm down here.

Genore, def_x was just trying to help please be a bit more understanding.

Def_x, that was a bit harsh but, I understand I would be a bit miffed if someone hinted that I had low experience.

Anyways back on subject, code wise I haven't got much time to figure out for "sure" whats violating DEP but, im fairly sure its the way we are using ssubtmr6.dll. There are functions in there that allow to hook on to other processes and change them. We use that in the autosize feature. I can disable that feature and check if it will pas DEP.

[PeaBea]

Not sure if this is the same error, but I've been getting this continually for maybe a month. Simply cannot update. Have to taskkill AP:

---------------------------
Application Error
---------------------------
Overflow

in prjUpdater.mdlDownloader.processDownloadQueue at line 173
---------------------------
OK
---------------------------

[ViroMan]

 PeaBea, on 16 April 2013 - 11:03 PM, said:

Not sure if this is the same error, but I've been getting this continually for maybe a month. Simply cannot update. Have to taskkill AP:

---------------------------
Application Error
---------------------------
Overflow

in prjUpdater.mdlDownloader.processDownloadQueue at line 173
---------------------------
OK
---------------------------

That line is where two numbers are added. Its saying that the two numbers combined are larger then the storage unit can contain. This shouldn't be possible unless your downloading more then 2gb at a time(another spot that has a 2gb limit that I will fix. Will add to todo list). To solve your problem try downloading 1-2 scripts at a time. Its cumbersome but, it should solve your issue till I fix it.

Edited by ViroMan, 21 April 2013 - 02:41 AM.

[PeaBea]

Thanks again. To my great surprise, I was trying to download more than 2GB. I don't know where that came from. I'm doing it in parts, and it seems to be working fine.

The other day I tried using AP on a netbook, and every time I clicked autopatcher.exe an installer came up for some online vault malware. The file size was the same as the version in my repository, so I don't think it was tampered with by a virus. It was quite a nuisance, and I wondered how it got onto AP.

[ViroMan]

Size doesn't really mater. A virus can tamper with an exe by compressing parts of it after a virus installs itself so that it remains the same size. The AP exe is not compressed or encrypted so it would be easy to tamper with via that method. The best way is to check its MD5. Current AP(v5.7.31) MD5 is 930F6D3CFFAE53AF5C4A8FEE69B2ADFA

[PeaBea]

Ok, thanks. I haven't had a recurrence. I guess it was a virus of some kind, which then got overwritten when I synced the usb stick with the master folder on my desktop.