Wuzzup from BugBopper: What do you think of it?

Thank you, but please say where the quarantine folder is located...!!!

Edit: I got that... C:\ProgramData\BugBopper

 

If you scan those 2 files again, you should see a different result -- likely no detection at all. I spent the last 8 hours straightening out the problem with NO_MALWARE Compressed: NO

 

In Windows 7 and Vista, the quarantine files should be in \ProgramData\BugBopper\BugBopper

In XP and earlier versions of Windows, the quarantine files will be in \Documents and Settings\All Users\Application Data\BugBopper.

The files are named with the format "Quarantine_yyyy-mm-dd.zip"

 

I've added the first two of these good ideas to our to-do list. But on the cookie cleaning: I don't want to give any more away than what we are now doing. Thanks for the suggestions.

 

I've made some good progress on this project. I'll give you a url for your review soon.

 

No problem..

 

Thank you .

Will Wuzzup's planned right-click scanning feature be able to get a Web-based report by hash also?

 

Great idea! I've added this to our to-do list.

Thanks for the suggestion.

 

When can we expect a new version?

 

Top part of Bugbopper's website Home page on 09/17/2010 Fri showed . . .


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

IMO the above is poor marketing of a potentially good product. The word "today" is undefined. The version number shown (1.1.0.9031) is wrong -- I now have version 1.2.0.9111 as of 09/17/2010.

Finally, BB's home page says "Today BugBopper shipped a new release -- v1.1.0.9031 -- with more features" BUT I could not find where BB ever listed those "more features."

No offense, but (IMO) it's not a home page for an app that wants to go big time.

 

Thanks for spotting these problems. Our marketing department isn't doing its job very well. I've revised the top of the page slightly. The first paragraph still contains a link to the press release, which opens with a description of those additional features.

 

I hope soon. We're beavering away.

 

Long time no post in this thread..

I am facing a problem with this. even after scanning is complete and upload is complete it fixes on the scanning window as if scanning is not complete. When I tried to close the window, it informs me that it is still uploading files. But there was no visual indication. A bug probably....

 

It does sound like a bug.

• Are you trapped on the Scan Progress tab, or can you flip to other tabs?
• Does this happen with every scan, or only sometimes?
• Is this a recent problem, or have you had it since the beginning?
• What happens if you click "Cancel All" in the middle of the Scan Progress tab?
• Can you send a screen shot?

 

1. I am not trapped, can flip to others.
2. It happens to all recent scans where I scan C drive for all extensions, but previously it used to complete.
3. It is a recent problem, 2 weeks or so.
4. I am going to run a scan now. Will update it.

Another bug. In my VM when I run a scan, it automatically ends after some time saying "file scanning is not completed".

 

Thank you. I've relayed these details to Jim, and added this report in our tracking database. Jim, though, would like the answers to my last 2 questions:

• What happens if you click "Cancel All" in the middle of the Scan Progress tab?
• Can you send a screen shot?

 

Screenshot of incomplete scan in VM
http://imgur.com/sCkLA.jpg

Screenshot of scan hanged in Real OS.
http://imgur.com/xXZqR.jpg
but I can move to other tabs.

 

Thanks very much.

Jim is wrassling some alligators right now, but I'll ask him to come over here, take a look, and leave you a note.

 

Thanks. For both cases I would like a screenshot of the very end of the scan log; I need to see which mesages appear there.
thanks

p.s. I just registered here, so if my posts lack a certain elan, or if I screw up somehow, give me time; I probably won't get better.

 

Hi Jim,
Welcome here.
Give me some time I will post that too...

 

Hi,
Uploaded screenies for the VM.







Will run scan on real OS tomorrow..

 

Thanks. This one is almost certainly a glitch in the transition from running an earlier Wuzzup to running current BugBopper on the same machine, and related to some arcana in Vista and Win7's hyperventilating security matrix. "Usually" it can be fixed by running BugBopper "As Administrator" once. 'Preciate you let me know how that works out.
You may also find that you cannot quarantine "some" files unless you run "As Administrator".
We've considered manifesting BB so it always runs that way, but that's ugly, and even more of a PITA than the few things that fail without it. I'm hoping the next release will at least fail a little more gracefully.

p.s. I just realized that you were running Wuzzup, not BugBopper. I think the answer is the same...

 

Hi Jim,
I am not sure if I understood properly. Are you saying that Bugbopper runs differently from Wuzzup?
As I am running that in VM I have not used Bugbopper. In VM I used administrator accounts...

 

Screenshots of scan in real OS

http://imgur.com/ZkuNc

http://imgur.com/tWh8A

 

A little more subtle. BB and WZ are the identical code apart from the quarantine and related features in BugBopper. But a couple of builds back we changed where the database, quarantine and other files are stored, and while they were originally different (and some duplicated) for the two products, they are now the same. The build that changed the location also moved and consolidated the files, but ran afoul of some of the aforementioned security poop in Vista/7, with the result that "sometimes" the ownership isn't right, and errors result.

In Vista/7, running with an Administrator account is not the same as running "As Administrator"; the latter can only be selected from the right-click context menu for the program or its shortcut (or can be specified in the shortcut's Compatibility properties), even if the current user is an Administrator (and if not, new credentials must be supplied). In Vista, that always results in a dark-screen system prompt; Win7 allows that to be bypassed by UAC (User Account Control) configuration if the current user is an Administrator.

Certain actions that are normally disallowed by UAC, like overwriting a file that is not unambiguously owned, are allowed when running "As Administrator", and that's the one that usually fixes the issue you stumbled over. (I doubt the VM itself is an issue, but it might be)

Once the hurdle is crossed, the file's ownership is cleaned up, generally the issue does not recur, and "As Administrator" is not needed for normal running.

Clear as mud, I know, but that's the world of Windows.