SSM Problems

I know there are other members here who use SSM like me. I'm having some trouble and I hope someone here can offer advice or share their experience.

SSM Problem with BOClean Ever since installing the V1.9.3 (Oct. 18 '03) SSM, it hasn't been playing nice with BOClean. After leaving the PC unattended for several hours, an SSM custom error message will pop-up, "Invalid Icon Index - Please, report error code 2/9 to bugsbunny@e-mail.ru" The only thing I know about the interaction between SSM and BOClean is that SSM 'application window' constantly tracks BOClean.EXE executing and then disappearing every few seconds. Most of the time there are no problems. However, after several hours, the warning message will pop up (almost always after some unattended period). After the error message, each new execution of BOClean.EXE will create a new line in the applications window - they no longer disappear after a few seconds - the new lines just keep piling up. SSM appears to be almost frozen - it doesn't refresh itself, but I can shut it down normally.

Memory Leak? As an experiment, I uninstalled BOClean for the past couple of days. SSM has not 'locked up' as before, but I have noticed that it does seem to occupy more and more memory until the PC is rebooted. With the PC at idle, SSM usually starts at about 5+Mb RAM. Over the past 48 hrs or so, it has steadily climbed - currently at 19.8Mb. I have plenty of RAM, although it's possible my pagesys filesize needs to be bigger.

Have been in touch with Max @ SSM. He hasn't gotten back to me with a fix. Any ideas here? Are the issues related? I think perhaps they are. Is it a memory issue, a power-saving issue, etc?

Thanks & Regards
Optigrab

- Corrected subject to get better attention to topic - LWM

 

Thanks for pointing me to this - BOClean *is* sensitive tot he memory leaks of others - that's one of the reasons why BOClean has the "excluder for poorly behaved programs" as an option (I intend to case NO aspersions on "SSM" ... I didn't discover it until someone else pointed me at it elsewhere. Seems pretty nifty, but does seem to get confused in the NT/2000/XP realm where permissions aren't what they might seem to be to a program. Only reason why I'm aware of what can go bump in the night is being into computers longer than Bill Gates, and have seen it all.

But *IF* memory locations exist that are reported as valid by the OS, and are not, any program carefully inspecting that memory space (even if it has junk in it) is going to kiss the sidewalk and take the system down with it as the remapping of memory causes the SYSTEM to run out of same. This is the way Microsoft has chosen to handle "unhandled memory exceptions" in just dying altogether.

INVALID memory locations are often exploited, so BOClean (and many AV's as well with "memory scanning" capabilities) will cause "resources" to die as they keep trying to access the "mystery meat" ... that's one of the most common "heuristic" signs that something's fishy, so any proper security program's going to keep trying to "get in there."

I note that the program is done in Inprise Delphi (whose ancestor is Borland) and while Delphi writes GREAT executables with tremendous stability (we use Borland C++, Inprise C++ builder ourselves) we've also come to realize that Inprise/Borland DOES have some problems creating DLL's with proper "hook management" since Microsoft never documented internals truthfully. For BOClean and other products we write, we have NO CHOICE but to create our DLL's and drivers in Microsoft Visual C. Wish there WAS an alternative, but memory leaks and other anomolies occur with DLL's done in Delphi ... that *might* be the cause of the consternation, as well as the strange results of interprocess communication.

There's a number of security programs out there that utilize the less expensive in programming "GetWindowThreadProcessId" (which is why trojans LOVE to use this function) ... it's easy and tells a coder who owns which window. Problem is, when a program throws up multiple hidden windows as a diversion to protect it, such use of code ends up producing duplicate and confusing results. Same here. There are more complicated and reliable means of determining what's ACTULLY running, what is real, and what is "radar echoes" but it doesn't come in the tutorials.

I suspect though, the problem IS in fact a memory or resource leak and it's occurring in such a way that the operating system itself can't "see" it and thus can't free it, and is left with an unguarded "guarded memory page" ... this is the kind of allocation that trojans and viruses LOVE to find, they can plug themselves RIGHT in there and use such holes, and that's also why BOClean is OBLIGATED to follow them into the breach.

 

Sorry for a second - shows you what happens with a preoccupied mind - we're redoing BOClean for a future 4.12 when there's a need to release ... I'm so obsessed with what's going on here on our end, that I didn't read your message here (and in the referring thread) carefully enough. Yes, it DOES seem as though SSM has its own memory leak - if a security program gets invalid information and has allocated memory to handle it, then an exception MUST be called internally on any kinds of failure to RELEASE that allocated memory, regardless of the reason for the failure. It's sad really - MSDOS used to do "routine garbage collection and FREEING of memory" and somehow that ancient art has been lost in Windows. Nowadays, each individual program must clean up after itself (self-bussing tables, please) or the OS will just bomb eventually. Sad that the OS once did this.

One of the biggest problems with newer software is that the "kids are smart" but they don't know what things used to be. What was never accepted as "sloppy coding" or "going AUTOMATIC" and DEPENDING on the IDE to catch is de rigeur these days. Writing code isn't as easy as it looks. No offense intended ... but I've seen MANY "newcomers" to "I'm going to be a software company and I'm gonna BE RICH!" ... heh. Ain't LIKE that. "Generated code" doesn't work well.

 

Kevin

How can I thank you enough? You've gone above and beyond (again) to share your knowledge with a puzzled neophyte.

Your posts have given me a lot to chew on, and so I will review and contemplate.

Boclean is essential on my machine. SSM is also important - hopefully it will adapt in future iterations.

Regards,
Optigrab

 

Max has always been great about helping me in the past.
Why not shoot him another email referring to this thread so he can get Kevins input.

 

Done.

 

Hi. Thanks for pointing me on this thread
I agree that it's a SSM's problem, and I'll do my best to fix it. Unfortunately currently I was too busy to do anything and also I was implementing a new registry monitoring engine in SSM, so I had absolutely no time to study this problem carefuly. However I believe that I will be lucky to do that until SSM expire (in December) and new release will be done.

Regarding a problem - there was a time, when SSM had the similar problem, but fortunately this bug was fixed. Now it has re-appeared somehow . The problem is that when I've done a crash-test on my system (one application executed another ~100 000 times approximately 100 times per second) everything was fine, until it's PID acheived 32000-34000 value. After that Outpost Crashed (I have not the latest version running).
If Outpost was not started, then there was a major memory problem (with or without SSM running - the same) : System was unable to create any new process. Even during a shutdown, my WinXP was looking like it was deadly injured: there were no graphics, just black background and Win2000-like startup/shutdown window....

So anyway, I hope that now I will have some free time to solve this.

 

Mmm... have I forgot to mention that after running a crash-test in user profile there were a sound system failure: winamp playing thread stopped while there were some terrible noise coming from my dynamics . Any application that played the sound did the same.

So does it mean that user with limited priviliges can do a crash and drive a whole system unstable

I've used the following code:
program megaexec;

uses
Windows;

var
e: dword;
begin
while 1=1 do
begin
e:=WinExec('nothing.exe', sw_hide);
WaitForSingleObject(e, 300);
end;
end.


program nothing;

begin
end.

Perhaps there is something wrong with my WinXP