Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About Geek4AllSeasons

  • Rank

Profile Information

  • Gender
  • Location
    New Jersey
  1. I was forced to remove IP from my system after a clean install of 3.03 as requested by support. The first and every boot after installing 3.03 displayed a Blue Screen. The message displayed said windows stopped a driver from corrupting the stack. It's a waste of time: attempting to diagnose a continuing stream of problems without the active participation/direction of Immunet support/developers. sending SDT files into a black hole installing beta quality (at best) software being passed off as releases investing time and effort in an attempt to help IP realize its potential when Immunet shows no regard for problems experienced by users. One can only hope Immunet or SourceFire management recognizes that there are problems and takes corrective action.
  2. It possible, maybe likely your issue is the same or closely related. There aren't enough details to be certain. IMO the Task Manager doesn't have enough of the right details for a clear understanding of process memory usage, Particularly, the impact on system responsiveness and/or throughput. VM size includes all modules mapped into a processes address space. Many system modules (dlls) that provide services and/or desktop integration are loaded into a process. Security is a biggie. File Unlocker Assistant is another example. Process Explorer, the latest versions in particular, provide the better information. Total Working Set size and Total Private Bytes are good measures process memory consumption. PE breakdown those totals into Private Working Set, Shareable and Shared components. I'm seeing agent.exe is stopping, but doesn't report that back to the issuer of stop control. The GUI waits for 10 to 20 seconds after the process has ended before reporting the failure to respond. I agree that 400 MB to 600 MB is a problem, but it may not be the immediate cause of degraded system performance. The availability of system resources to other processes is more significant than the amount of resources used. Simple how much headroom is available. The VM size may have been as large when agent.exe was misbehaving on my system. I didn't pay attention, because agent.exe eating up so much I/O and more importantly Non-Paged Pool, the system was on the verge of crashing. The I/O rates were high enough to overwhelm the system cache driving the disk hard enough to raise its temperature over 130F. The Non-Paged pool is kernel address space locked in to physical memory used by device drives. If it is exhausted the system locks up. That in it self is a useful data point. I it were not too inconvenient it would be important to know if non-paged pool was leaking. On my system agent.exe also cased Microsoft Update to fail by locking a file that it wanted to delete.
  3. As requested 4 files have been uploaded to MediaFire and an email sent to support. For each file there is a cross-reference link to a thread describing issues experienced at or near the time the file was created or a short description which is described in a subsequent thread. There appears to be some moderately good news and some not-so-good news. Since tweaking the history.db page, I/O rates have been substantially lower. Process Explorer reports (5 sec,update) total I/O for agent.exe a constant 7.8/9 KB. It jumps to +1 MB to +7 MB when updating history.db for a period of time. During an install or similar system activity the I/O rate would be proportionately and significantly higher. The not-so-good news is in an approximately 24 hour period non-paged pool allocated to agent.exe went from an initially steady 24KB to +2,500 KB. It now is clicking up 1 KB every 10 secs (every other Process Explorer update). The "negative" editorial comment stems from invalidation of a basis to speculate about a possible connection been leaking NPP and abnormally high I/O rates. I run windows on legacy hardware, XP SP3 (fully up to day) on the following platform: P4 2 GHz, 1 GB DDR 266 MHz, PCI 133 MHz. I've encountered what appears to be race condition/un-handled (lost) event problems. The speculation was that very high I/O rates could conceivably cause NPP and/or system file locks to leak. However, to my knowledge I/O rates have not been high (actually rather low) in the past 24 hours. It seems that further investigation will be needed to find the cause.
  4. Remote sessions/assistance is built into Windows. Not certain about secure connections, but would be surprised if it wasn't the default and/or an option, I am working out details with Petersen. Worst case the SDT files can be put on a server for support to download. Assuming my hypothesis is proven correct eliminating the immediate DB I/O rate problems/symptoms would be a by product. Implicit policy issues, history retention/archiving and database maintenance procedures for example, require consideration of requirements/options and additional, but not much, more effort to implement. The non-paged pool and system file lock leaks observed are likely separate and will be challenging to resolve. I have a large collection of debugging/diagnostic tools and system utilities available. Some are used to analyze Day 0 malware, I can collect a wide range of data/information if I know what would be helpful. IMO remote sessions are best used for one off, time critical, and the gnarliest situations. Their drawbacks are being reactive and lack of scalability. There's more magic in the "Cloud" than instantaneous distribution of Day 0 threat signatures.
  5. I ran the System Diagnostic Tool immediately. At 45 MBs it is too large to be emailed. Details to send it to support are being worked out with Pedersen. There are 3 additional SDT files generated, but not submitted in connection with issues reported in other threads, They will be submitted as well. Snapshots taken over time may be useful.
  6. I have a hypothesis which identifies what is causing agent.exe to generate extreme I/O rates for some, but not all users. Fortunately, if proven correct, it's an easy, almost trivial fix. While simple to correct, the problem is a gross misuse of SQLite. Ataraxy's concern was appreciated and his reply very helpful. I had used the System Diagnostic Tool before, but thought it was worth checking out the link he provided. As soon as I learned that log files are SQLite databases, the dreaded "Table Scan" shot to the top of the most likely suspects chart. "history.db" has 1 table, a simple heap, entry sequenced list. The problem is it doesn't have any indices. Most importantly no primary index, which specifies logical table order. If it's a B-Tree or derivative, physical order as well when table pages are contiguous. It appears that SQLite has a pointer in the DB header to the first page of each table. Each page has a link to the next and to the first/ When a row is added it finds the end of the table by following the links on each page. Is any one still awake? I'm putting myself to sleep. :-) The cost of a query is (loosely) measured in DB (database) I/Os Each page access is 1 DB I/O. Table Scan are know to generate combinatorial increases in DB I/O processing a query with 1 or more table joins. In this case the increase is geometric where N = the number of pages allocated to the table. My history.db had 210,402 1 KB pages before tweaking. Each row added to history would produce 210,402 DB I/Os. The magic of B-Trees would create a logarithmic reduction to 3 or 4 DB I/Os to find the table end. After tweaking a page size of 16 KB the number of history.db pages was reduced to 10,928 and database size 174,768 KB. More rows in each page, less slack space. A 94.8% reduction in page count, DB I/Os per row added and an allocated space reduction of 35,634 KB (17%). Indices for historyex.db and Cache.db should be evaluated as well. There maybe significant performance gains possible. Agent.exe started acting up after installing Libre Office. An immediate uninstall/reinstall was the killer. Adding appropriate indices and or adjusting DB page size would require little coding. It should be done tuning production queries. IMO, if proven correct, this is a significant defect. Using the number of users immediately affected, to determine priorities, has limited value. It isn't clear that the non-paged pool and/or system file lock leaks reported in the first post in this thread are database query related. I would guess not. They could cause system problems up to and including lockups and/or crashes without manual intervention. It is possible agent.exe is exhibiting symptoms caused by other software. Prevx and Online Armor are installed. Both have been very stable and unobtrusive. I have invested significant effort, out of a desire and sense of obligation to contribute. Continuing would be a waste of time without an indication of interest from the project team. Other open source projects face similar challenges. Development process support and remote monitoring/diagnostics are areas I have been working toward offering dynamic, proactive and scalable contributions. david
  7. Agent.exe has been having hyper-scanning episodes. Every system start-up (actually logon), during software installs and other seemingly random times. CPU usage can be high. A constant 80% to +90% is not uncommon. Adjusting its process priority is blocked. By far the biggest problem is its I/O rate. Constant single to double digit MB's with intermittent bursts well over 100 MB. The highest I've every seen, except for I/O speed benchmarks setting off disk temperature alerts (+130F). It has also blocked windows update by holding locks on system files. The following is an example from the Event Log: Unlocker Assistant has reported a lock held by agant.exe Recently agent.exe has been leaking Non-paged Pool memory. It was discovery when my system became unstable. It had been running for several days. Process Explorer reported +90 MB of Non-paged Pool allocated to agent.exe. Restarting the service relieves the problem temporarily. A gui restart times out waiting for the service to shutdown requiring the service to be started manually. Earlier today, agent.exe had +3 MB of NPP allocated. The output from system diagnostics tool run at that time will be emailed to support (+45 MB). At time of this writing the NPP allocation had grown to +9 MB. Contact me if more information is needed. An explicit response/status would be appreciated. david
  8. Thread Iptray Crashing When False Positive Restored is a variation or related issue. Iptray has been added to the DEP white list.
  9. Multiple false positives have been by Immunet/ClamAV while unpacking Serious Samurize addons. Iptray has crashed intermittently after files have been restored. At times DEP exceptions have been reported. See forum post: Immunet Tray Client Closed - Dep Exception Several crashes have occurred without a DEP exception reported, including one today. WinPcap_3_1_beta_3.exe was quarantined then restored. A VirusTotal scan (WinPcap_3_1_beta_3.exe Analysis) reported 0 positives from 42 scanning engines, including ClamAV. It isn't clear if this is same issue or not so a new thread was started.
  10. Immunet's tray client was closed by Windows Data Execution Prevention. It happened soon after restoring MemuMaker.dll. It was quarantined while installing a Samurize config: Multi-Fontion 3 Pack. The ClamAV detection appears to be a false positive. Virus Total reports ClamAV is the only scanning engine registering a positive out of 42. VirusTotal Analysis A copy of MenuMaker.dll is attached. OOPS. It was rejected for upload. I can send it via email if needed/ I don't recall any DEP exceptions and its suspiciously coincidental, but I've seen some strange things happen that turned out to be benign. The file was unzipped by Total Commander then restored through Immunet's history dialog. About a minute later the DEP alert popped up. As far as I know the dll was not registered, executed or loaded. Should the tray client be excluded from DEP? Is MenuMaker.dll a legitimate false positive.
  11. I'm dealing with Explorer crashes since upgrading from 2.0.19 to 3.0.0. The problem is different, but based on your description the timing is the same. I would like to offer my view (opinion) about Immunet's role/responsiblity, which differs from yours and rayray23 and offer suggestions/options that could contribute toward recovery. System corruptions are part of life with windows. Registry semantics are not monitored or enforced in real-time. At best an alert will be displayed when a change is about to be made. There are independent utilities that scan for and correct errors after the fact. It is tempting to blame the most recent program that changed the registry/system. It is the logical place to start looking for the cause. In my experience, it's not wise to make assumptions and/or draw conclusions without supporting data/info. Installing 3.0.0 appears to have precipitated my Explorer crashes. While investigating some small related problems were found that were around long before. There are apparent problems Immunet's interface the cause will not be determined until the point(s) of failure is(are) known. Today all platforms are complex. More so then mainframes back in the olden days, They had staff, as in teams of people, dedicated to their care and feeding. IMO Window's greatest weaknesses are the registry and sub-system inter-dependence. Applications have to make reasonable assumptions about the installation environment. Alternatively, IMO, software should handle irrational inputs rationally. Collaboration could be a middle ground and beneficial to Immunet and the community beyond users with boundary use cases. Immunet should have sufficient domain knowledge and experience to guide users. Information gain could identify small changes which prevent big problems. Using a Live CD has been suggested. There are Linux CDs with Windows diagnostic tools and utilities. BartPE CD is a windows based alternative. You cannot know what's wrong unless your system disk mounted. Big problems can have relatively painless solutions. Corruption of registry security descriptors are a frequent cause system boot problems. There are numerous tools for making such a repair. If any security scanners have been previously uninstalled, even if it was recently, drivers may have been left. I've seen that myself more than once. I can understand why you're upset. Windows admin takes far too much of my time. I have a huge investment in my systems and a growing investment in a large collection of diagnostic/anal-retentive maintenance tools. Security concerns are expanding explosively. Systems Administration issues should be addressed at an industry level. Defining standard practices and reshaping the focus projects/companies would provide a basis for lessening/sharing the burden.
  12. Will do. BTW, I'm not recieving forum notifications. I'll double check the spam filter/folder.
  13. Explorer is crashing repeatedly since installing 3.0.0 over 2.0.19. Crashes occur predictably after each re-boot/logon. Prior to installing 3.0 crashes were few and far between. Maybe less than a handful a year. Restart is immediate, but not all notification area icons are recovered. Subsequent crashes tend to happen soon after, but may not until the next reboot/logon. Searching the forums didn't find any similar problems, would indicate one or more issues/incompatibilities in my environment. After resolving a symbol path problem, windbg !analyze -v user.dmp reports the exeception occurrs in: BAD_INSTRUCTION_PTR_c0000005_explorer.exe!CTray::_MessageLoop At logon, a small empty Immunet window is displayed most of the time. When it isn't a non-functional taskbar button (Immunet icon) exists without a SystemMenu property. Removing the visible property from top and two levels of child containers eliminates the window without killing iptray. Now that I think about it, iptray is not recovered when explorer restarts. As per MS KB article, uPNP and SSPD are disabled. StartupDelayer manages logon process creation. Immunet is running on a loaded (running lots of stuff) highly tuned/optimized legacy hardware platform: P4 (2GHz), 1 GB DDR2 (266MHz) FSB 133MHz. Timing/race conditions are plausible. The standard brute force uninstall/reinstall is next on the list. It's been awhile since this system has been BootVis-ed. It might eliminate any timing load-order issues. It's a big search space. Any and all suggestions/help would be greatly appreciated. I played with the diagnosticTool. Let me know if and where to send the output.
  14. Version 3.0 worked! It didn't complain about mingw-get-inst. For now I'll assume it corrects other recent false positives. It seems to be faster/less resource intensive. (Yeah!) Total boot/login time appears to be faster. Maybe overall system responsiveness, too. After the initial restart, Windows Explorer crashed twice and Total Commander croaked once. Much too soon to tell who's not behaving. The system config is a little hairy. There are 97 processes running now, which is typical.
  15. Ok, will install the new version. I have been getting other false positives. Just now ClamAV for Windows would not let me download: mingw-get-inst-20110316.exe from Sourceforge. It would quarantine the file and I couldn't click restore fast enough for the download to succeed. Maybe options could be adjusted, but it makes more sense to install the new version first. I didn't receive notification of your reply. I thought I selected that option.
  • Create New...