You are currently browsing the Pandora Computing, LLC: Official Blog blog archives for April, 2011.

Posts Calendar

April 2011
    Dec »

Archive for April, 2011

A Quick-Fix Approach to Regaining Control of Internet Explorer

Wednesday, April 20, 2011 @ 11:04 AM
Author: krusta80

Whether your teenage children have turned your home PC into a digital Petri dish or you were simply unlucky by clicking an innocent-looking yet malevolent link while at work, odds are you are here for one reason:  your browser is out of control!

Bad news first!

You are likely infected with some sort of malware.  “But I already have an antivirus program,” you say?  Well, unfortunately many antivirus programs either admittedly leave out malware from their list of checked bugs, or they simply aren’t as effective as they should be.  The result…as you are probably by now all too aware…is a mess on your screen.

Onto the Good News!

It is usually relatively easy AND free to substantially improve the current mess you find yourself in:

  1. Restart your computer into Safe Mode.  You can do this quite simply by physically turning off the computer and then turning it back on.  The moment you see any sort of characters on your computer screen, start tapping the F8 key on the keyboard once per second or two until you are presented with a Windows boot menu.

    *** NOTE:  If your computer still starts the usual Windows screen despite your attempt to get into Safe Mode, you didn’t start tapping F8 quickly enough!  On the other hand, if your computer gives you a message indicating a problem with the keyboard, or if you enter some other, unmentioned screen, you starting tapping F8 too quickly!  Try again and wait a little longer this time.
  2. Once in the Windows boot menu, use the arrow keys to select the entry entitled “Safe Mode with Networking”.
  3. Be patient as windows starts up.  You will see a long list of file names listed on a black screen before you get to the more familiar Windows interface, but this is perfectly normal for Safe Mode.
  4. Windows will likely ask you a question about whether or not you want to proceed into safe mode.  Click “Yes” to proceed and login as you normally would (if necessary).
  5. If you are up to this point, then try opening internet explorer…in the majority of cases, you should be pleasantly surprised to see that it acts normally.  If it doesn’t then you likely have a pretty nasty situation on your hands!  Shoot us an email at, and we’ll be happy to help!
  6. If you are happily browsing the web again, then great!  Now you can actually try to fix the problem, but if you are ok with using Safe Mode until you get someone more technically oriented to look at the computer, you can skip the rest.
  7. There is an excellent, free program available on the web called Malwarebytes.  Check it out at  From the number of downloads and popularity, it is clear to see that we are not the only ones that believe the program is quite effective.  Download it and install it.
  8. Once you start it up, make sure you let it update itself before you perform a “Full Scan”.  The scan may take as long as an hour or two, so feel free to catch up on your favorite TV shows as you let this run.
  9. Upon completion, click “Results” to see what it found, and then choose to have it clean all infected files.  Since you are in safe mode, it should be able to clean up everything it finds.
  10. As this is a quick-fix approach (see title), we will stop here BUT keep in mind that it would be wise to invest in a GREAT internet security program right now!  Our favorite is Norton Internet Security.
  11. The last thing to do is reset all of your IE settings to their defaults.  This will prevent any unwanted toolbars and/or other nuisances from popping up after you reboot.  To do this, download Microsoft’s “Fix It” tool straight from there website:

    **NOTE:  Be sure to read the instructions carefully, as you should with any fix-it program/procedure.
  12. Well, if you made it here, then you are all set to reboot your PC and enjoy the fix!  Remember what we said about a good internet security program before…I would strongly suggest you get one and install it before visiting any other websites!

Again, we realize that this method will not work for some more severe infections, but we encourage you to reach out to us with any particulars that you may run across.  As mentioned before, either email us or leave a comment below!

–John Gruska

Post to Twitter Tweet This Post

Organizing the Captain’s Log

Monday, April 18, 2011 @ 08:04 AM
Author: krusta80

Alright, I admit it!  I am a pretty big Star Trek fan.  While most of my friends growing up daydreamed about scoring a winning touchdown or hitting a game-ending shot at the buzzer, I would spend hours exploring the galaxy with Captain Kirk and Mr. Spock.

Once in a while…when the weather was particularly bad and I had run out of video games to keep myself occupied…I would ”coax” my younger brother into watching Star Trek marathons with me (sorry again for that, bro).

And while the dates would change, almost every episode started with the same narrative spoken by William Shatner or Patrick Stewart:  ”Captain’s Log, star date 43125.8″.  And just like that, I was hooked again…transported back to the final frontier.

While I’m sure it is no stretch of the imagination to think that an IT professional would also be a Star Trek fan, there actually is a point to my mentioning the ultimate science fiction show today:  log files.   Just as it is for the captain of the Enterprise, keeping a recorded history of important events and problems is critical to maintaining a healthy and robust office network.

All too often, log files get lost in the shuffle.  After all, why would anyone need to investigate them if everything is working properly??  Any why wouldn’t we expect everything to work properly?  We ARE pros after all, aren’t we?

And then, of course, there is the real world to consider:  Murphy’s Law in action.  Something goes wrong one day…often months after the initial setup is done!  By then we have fixed dozens of other issues and have written hundreds — if not thousands– of lines of code for other projects.  Our mindset has since moved on, and we are forced to relearn much of what we had created.  But of course, none of that matters in an emergency situation, and it often is just that:  en emergency situation.

This is when a properly-generated (AND properly organized) log file comes into play.  It can mean the difference between spending a few minutes pinpointing the issue and wasting hours through trial and error.  And as we all know, during a critical outage for a client, there is nothing worse than wasting time on something that “should have been working in the first place anyway.”

Simply put, the client normally won’t know about… and CERTAINLY won’t and shouldn’t care about an unexpected change caused by the latest Windows patch or a problem with the local DNS server.  It is up to you to dig up that log file and find out what is causing the failure.

So, without further ado, I give you Pandora’s top tips for creating and managing your log files:

1.          Whether developing a program from scratch or simply implementing a set of out-of-the-box programs and/or scripts, print everything to the screen first.  You will likely need to do this anyway for the initial setup, but it is also a good way of visualizing exactly what messages are critical to the program’s success and/or failure.

2.          Once the new process is configured properly, it is time to redirect all of those important print statements to files.  This is when I like to run through the basic questions:  what, when, who, where, and why/how.

a.  What:            Remember, this wasn’t your first program and it won’t be your last.  So identify what the name of this process is, both as part of the file name and as the opening line(s) of the log file!

b.  When:           The more precise the better!!  Every line in a log file (and the file name itself) should have a timestamp.  The human mind is amazing at pattern recognition, so give yourself a chance at picking up potential timeouts or other things when investigating a problem.  Particularly with network issues, timing is everything.

c.   Who:             Every operating system…especially these days…makes security a priority.  It is possible to have dozens of levels of access, both per user and per group.  Therefore, it is very important to keep track of what permissions  were used when running the process.  Was it run as “root” or “administrator”, or was it something written for “Bob”?  If the latter, were Bob’s credentials recently changed for any reason?

d.   Where:         The price of data storage is plummeting, and the average hard drive size is rapidly expanding.  It is therefore more important than ever to keep track of where your files are read from and written to.  It is equally important to keep track of each active sub-process (with absolute path info included) at all times.  During troubleshooting, this info comes into play mostly when system updates or some subtle change made by a seemingly independent process is to blame.

e.   Why/How:   These are basically the same question when it comes to computers, and unfortunately answering why or how something is not working is often left up to us.  But that said, there are still ways to help ourselves here, and this is where multi-level debugging comes into play.  For example, CUPS, which is an open-source printing subsystem implemented by most Unix/Linux servers, allows for two levels of debugging:  1 and 2.  While level one is normally sufficient to handle the most basic of issues, sometimes you need to dig a little deeper!

3.          Determine how critical this new program is to operations, as well as whether it is intended to be completely automated or part of a manual process run by a user.  The more critical and automated the program, the more you need to consider setting up a notification system.

This is where things get a bit dicey for us IT people.  The more processes that we deem “critical” and send ourselves notifications for, the more clogged up our inboxes will get with automated messages and log-file attachments.  No matter how hard we try, it is human nature to automatically apply some sort of visual filter when overwhelmed with things.  Our eyes and  minds will naturally gloss over messages over time, especially if there is little difference between a harmless warning email and one indicating a critical system failure!

So while it may seem counter intuitive at first, DO NOT send yourself an email for any little thing out of the ordinary when you create or configure a new system process.  Separate the critical errors from the warnings, and remember that there is no better notification system than your end users!  If the script you setup is part of a daily routine run by a person, let THEM be your notification system…trust me, they will let you know when something is wrong!

Note that limiting notifications does NOT mean limiting log files altogether.  After all, even for the less severe issues, you will need to dig into the logs eventually anyway.  But by keeping your email notifications limited, you are in
effect streamlining your efforts for your clients.

4.          Bad news first:  log files can often take up lots of disk space.  Since they are constantly written to, it is not uncommon for log files to quickly gobble up hundreds of megabytes of space.  The good news?  Well, since log files normally
consist of repeated text messages, they are highly compressible…so what was 100 megs before compression can easily be converted to only a handful of megabytes as a zip file.

Be sure to archive your log files carefully!  While it is best to have the source program assign a separate log file to each hour, day, or other predetermined time period, you can always accomplish the same task independently if need be.  In fact, I will actually be exploring how to do just this in a future post dealing with “grep” and other powerful parsing tools.

As alluded to before, be sure to compress your archived log files accordingly.  Whatever the cutoff date is for when to archive a log file, make sure you have one.  Your server’s hard drive will thank you for it.

5.          As with everything you do, it is critical to keep your client’s logs organized!  Whether dedicating a directory on the hard drive for storing all log files on the system or simply including each process’s log file location as part of your documentation, make sure you know where to begin when troubleshooting a process.

6.          Finally, we need to know how best to navigate a log file when the time comes.  Log files can often seem like mountain faces of information, and they are best scaled with powerful parsing tools (again, more about this in a later post).

There is no room for guesswork in our business; we are the ones others look to for answers.  With the right tools in place, log files are the blueprints of problem solving.  Treat them as such, and they will never let you down.

Post to Twitter Tweet This Post