We have all had many a giggle at the online postings of idiotic support calls/email that tech support staff have had to deal with from people that clearly shouldn't be allowed to own a computer, so I thought I would share a few of my own. Just when you think you have reached the limits of stupidity and no-one could ever ask or say anything more dumb, someone comes along and surprises you.

I recently dealt with a customer who had registered a domain name, signed up for hosting and had the holding page up and running but could not get his site to work because he would not upload it to the correct place (wwwroot). No matter how many times I told him that his site needed to go in the wwwroot he would not listen as he thought he knew better. In the end he decided to take his business elsewhere because we supposedly had no idea what we are doing, he was advised how to transfer his domain, but then decided for some bizarre reason that we were with holding his domain and stopping him using it, even though he had already changed the name servers and pointed it at his new host. He then claimed that his domain name had not even been registered and we had ripped him off, despite the fact that he was able to view the web site with the holding page, he had edited the name servers to point it elsewhere and the WHOIS showed it was in fact registered.

Here are some of the incredible rantings I got from this chap. Now I accept the fact that some people are simply not very I.T literate, and that is understandable and most of those people are aware of their limitations and openly admit them, but this crazy guy actually claimed to be an I.T professional and is a MCITP and a member of ACITP (wooo) , which is why I thought this utter lunacy was actually worth posting as my 5 year old son knows more about the internet than this guy. And no I don't even have a clue what he is talking about most of the time, and his inability to write coherent English or use punctuation doesn't help either:-)

Read more...

The inevitable has been happening the last couple of months, my windows XP machine has started to become slow and unstable and prone to crashing and was due for a reinstall. Never a task one looks forward to when you have a lot of software installed, much of which you do not have CD's for and have no idea where any of your driver CD's are either.

I had a spare machine sitting around on which I had installed Windows Vista for testing, and so I was about to bite the bullet and start using that instead of re-installing XP. Then a friend of mine suggested I try Windows 2008 server 64bit. He said he had switched from Vista and it was definitely a better experience and all of his software worked.

Well as I subscribe to the Microsoft Action Pack I had a copy of 2008 Server Std edition, so I thought I would give it a try, although I was very sceptical  about all my software not only working in 2008 Server but also working in 64 bit. But as a web developer it is much more convenient to run a server OS and have to work within the limitations of your workstation. For one you will have a full copy of IIS at your disposal, so no need to go messing about with Apache if you don't have to, and to be honest the only reason to bother with Apache these days is a) because you are on Windows XP and have the 1 site limited version of IIS or b) because your live sites run on Apache. There may be some instances where you need a very specific feature of Apache, but for most people this is very unlikely as IIS has been able to do everything Apache can do for quite some time now, and with IIS7 you are more than spoilt for choice with new features and configuration options.

Read more...

My Microsoft messenger popped up an alert yesterday telling me there was a new version and did I want to get it, so I clicked yes.

This time instead of just Messenger being updates I got this new "Windows Live Essentials" installer that wanted to update all my windows live products in one go, which I did find a little annoying, but I let it run its course anyway. At the end all of the updates to all products had failed, showing a message like the one below.

Microsoft Application Error Reporting - Programs were not installed because the program was cancelled. Error: 0X80004004

Now obviously I had not cancelled the install, so presumably one of the updates had failed causing the whole process to cancel, how daft is that Microsoft?

The first thing I did was Google the problem, and I found lots of people with this issue, but no solutions. In fact I saw several so called windows tech's even passing the buck on this one and just sending users to some useless windows live help page to get help that said nothing more than re-install your application.

So I ran the installer again and watched it, it got to the Windows Live Toolbar (WLT) and this is where it failed and rolled back the rest of the installation. If you actually look at the error messages on each component at the end of the failed install it does actually tell you which one failed, all the rest will just say they failed due to being cancelled.

So I thought I would just un-install the WLT, which would solve the problem, if only it were that simple. Every attempt I made to do so had no effect, no uninstaller appeared and nothing happened. A bit more Googling and I discovered that the WLT was linked to another program called “Windows Live Toolbar Favourites�, so I un-installed that first, which then allowed the WLT un-installer to run. But alas this didn't get me much further as the un-installer now wanted me to insert my "Windows Live Toolbar Disc" as it couldn't find the WLToolar.msi. Of course I had no such disc and this now presented another problem because thanks to this new Windows Live Essentials. it is no longer possible to download the individual installers, so where was I going to get this wltoolbar.msi?.

I was not able to get the MSI, but I was able to get the updater component from the windows update site which contains the msi, you can download it <<HERE>>.

1. To extract the MSI file you will need a Resource Editor. I used ResHack for this.
2. Open the EXE file that you downloaded in the resource editor
   
3. Select the 0 in the MSI tree section then select Action->Save Resource as a  binary file and save as wltoolbar.msi
   
   
4. Now you have the MSI which you can run

If You now go to add/remove programs and uninstall the WLT, when it asks you to insert the media, just browse to your new wltoolbar.msi and it should now successfully uninstall.

This same method should work with any of the other Live components if they are the cause of the problem. Try to uninstall them first, if you are unable to uninstall due to the same issue I had above, then download the exe from windows update and perform the above procedure to get the msi.

Here are direct links for all the windows live components

Sign-in Assistant (4.200.520.1)

Windows Live Mail (12.0.1606.1023)

Windows Live Messenger (8.5.1302.1018)

Windows Live Toolbar (03.01.0146)

Windows Live Photo Gallery (12.0.1308.1023)

Windows Live Writer (12.0.1366.1026)

Windows Live OneCare Family Safety (2.0.5817.2)

Windows Live Writer Update (12.0.1367.1128)

For the last few weeks on one of our ColdFusion 8 servers I have been noticing an increase in performance issues. Requests would regularly start taking longer and timing out and it would often be happening to all the running requests and not just some. Strangely this also seemed to happen whenever I modified a security sandbox, which would usually take a long time to process the request and would also cause all other requests to slowdown and timeout as above.

One common factor I noticed while stack tracing these requests with FusionReactor and the server monitor was that they all seemed to be using Fusebox and there was a lot of class loading going on.

Now I know that frameworks like Fusebox and ModelGlue can be slow to initialise the first time as they have a lot of classes to load, but this shouldn't happen again unless an application is re-initialised or CF is restarted.

I had Charlie Arehart helping me look at this issue and he reminded me of the problem with Java 6, which I had totally forgotten about. For all the other performance improvements and increased functionality in Java 6, it introduced a bug in the class loader that causes substantially slower class loading. You can see a discussion of the problem on Sun's forums.

This bug will affect any application using a lot of CFC's, especially those using frameworks such as fusebox, ModelGlue, Transfer etc, due to the large number of classes that must be loaded as a result. So for those of you not caching your CFC's, perhaps it time to start doing so.

This lead us to the conclusion that whenever you make any changes to a security sandbox this causes all existing classes to be reloaded, which seemed to be confirmed by the stack traces which did show a lot of class loading happening in the slow running processes.

As the aforementioned bug is supposed to have been fixed in the current release of Java 6, I decided to go with Charlie's suggestion and give this a try and see if it resolved the problem. So I downloaded and installed the JDK 6 Update 12, set ColdFusion to use this version and so far I have not been able to repeat the previous issues when modifying security sandboxes, so it seems as though this solution has worked. It is however early days as I only made the change last night, so time will tell if this gives an overall performance boost to ColdFusion in general.

Updating ColdFusion to use a newer version of Java is very straight forward, so here are the steps for anyone interested in doing so.

Download the latest version of the JDK (or whatever version you need) from http://java.sun.com/javase/downloads/index.jsp

Now install this on your server in your desired location, but don't forget that you may need to setup additional permissions if you are not running ColdFusion in the standard configuration and have it running under anything other than SYSTEM.

now you need to edit your jvm.config file and modify the java.home path to point to the newly installed JDK.

On a standard installation this file can be found in c:\coldfusion8\runtime\bin\jvm.config, if you are using a J2EE or multi-server installation then your path will be different.

Comment out the existing java.home by adding a # to the start of the line and then enter your new path like so:-

#java.home=C:/ColdFusion8/runtime/jre

java.home=C:/Program Files/Java/jdk1.6.0_12/jre

Please note the path is using back slashes and not the default forward slashes that you will get if you copy and paste the path from windows explorer. This is required or ColdFusion will not start. If you are running multiple instances of ColdFusion with each using their own JVM.config then you will need to make this change in each jvm.config file.

Now simply restart ColdFusion, then login to your cfadministrator and go to the system information page, where it shows which version of Java is being used, which should now reflect your changes.

ColdFusion 8 Server Monitor

I also wanted to mention that while trying to diagnose these issues I tried using the built in server monitor, which unfortunately caused more of a hindrance than a help. It seems that enabling the Profiling and Memory Tracking on a live production server may not a good idea and could well bring it to its knees within minutes. While these options were enabled the JRUN memory usage started to climb and continued to climb until the max 1024mb had been consumed, at which point CF will stop responding. I also noted the memory tracking will also incorrectly report the memory usage of complex FuseBox variables, stating that they are several TerraBytes in size, so this seems to imply that again the problems were related to frameworks and class loading.

I have however enabled the server monitor briefly since updating Java and the memory consumption problem does seem to have gone but the incorrect reporting  of memory usage in application and request scopes is still there.

Sadly I have never been able to get the "Sessions by memory usage" or "CF Threads by memory usage" to work, they have always been blank, so whether these have the same issues I do not know.