In my opinion, one of the worst things ever to come out of Microsoft is the Windows Installer Cache. Actually, I shouldn’t be that harsh. There is a worse thing that is behind the problems with the Installer Cache.
The cache is a hidden folder located at %WINDIR%\Installer. If you have been running Windows for any respectable length of time and installed a few programs to use; you will see that this folder is filled with MSP and MSI files. It is quite possible that many gigabytes of space are taken up with these files.
The curse of this design is that many users will delete these files to gain back that space. The consequences of which are that many programs (notably, SQL Server) will break during future upgrades or installs. Sometimes this problem is so severe that the best answer for resolution is formatting and reinstalling everything.
That is where I find myself this morning. I bought a 32 GB solid-state drive to install Windows on. But I forgot about the piggish Installer Cache and the drive quickly filled up completely. I moved some of those offending files (rather than delete them) to larger spinning-rust drives. This is merely a Band-Aid temporary solution though.
Today, I will add a new 120 GB SSD drive to my box and rebuild.
I hate rebuilding. There is always something that I forget to backup.
The "worse thing" that I initially mentioned is that Windows Setup should come with advanced options that give one finer-grained control about file location. These options may not be for everyone; but they should exist!
Please Microsoft, I’m begging you! Let me choose the location for the Windows Installer Cache during setup!
I have been contacted directly by Adobe’s senior support team. Apparently, this blog played a factor in that. I do wish that a public rant here was not necessary.
The good news is that a local reproduction has been confirmed. A tight repro of the problem is crucial to assisting developers with a fix. Now that a bug has been filed, I’ll be continuing to provide Adobe with information if necessary.
We may use the XPerf tools to profile the Dreamweaver process. I am thrilled that progress is being made now and it is great knowing that a great product will be made even better.
I have been quite vocal at work about my problem with Dreamweaver CS5.
I haven’t used Microsoft’s own Expression Studio product – it would be interesting to do a comparison though. As I told my colleagues, I have been using Dreamweaver since it was owned by Macromedia. Back then, Microsoft’s web site editor was Frontpage and that was a piece of garbage that should never have seen the light of day.
My friend Bill has some experience with Adobe products too since his wife is a desktop publisher. It was his suggestion that I try using a 10×10 pixel PNG rather than a 1×1. Interesting idea…
Lo and behold, it worked quite nicely! Although the kernel mode time still spiked, it returned back to user mode much more quickly and let me type directly into the Design Mode window – which is the expected behaviour. I started experimenting with different dimensions for the PNG file (always using Fireworks CS5 to resize as desired).
As you can see in the Performance Monitor trace, the kernel mode time for the Dreamweaver process still spikes while I am typing in the Design Mode window. However, it quickly drops back and the typing remains responsive. This was captured while using a PNG image 890 pixels wide (the full width of my page content <div> tag) and 10 pixels high.
The trade-off is that the PNG file is a larger file size; but with today’s internet access rates, this should be hardly noticeable.
If any reader uses Dreamweaver and experiences this issue, I hope this post helps you out. I am also curious to hear from people who have used Adobe’s free technical support; how were you treated?
I suspect that most users would prefer to avoid calling technical support. Regardless of the company in question; this is simply not a fun way to spend your time. Adobe support is certainly no different.
The case was free; the aged adage "you get what you pay for" couldn’t be more glaringly obvious here.
The first gentleman that I spoke with clairvoyantly diagnosed my problem as corrupt files and insisted that there was no bug in Dreamweaver. As if intentionally trying to piss me off further, the support case was closed and marked "resolved." Bullshit.
But I decided to tighten up my own troubleshooting. I created a brand-new web site in Dreamweaver CS5 and used Fireworks CS5 to create a new single-pixel PNG with transparency enabled. Of course, as with the files from this blog site, Dreamweaver’s Design Mode rendering chewed up kernel mode time. The moment that the PNG background was removed, kernel mode time barely showed up in my Performance Monitor traces.
I called back and created a new free support ticket. This time, the support engineer spent a couple of hours on the phone with me. I let him record my desktop so that everything we did would be documented. We reproduced the kernel mode time spikes at least a dozen times. We created a new background graphic in JPG format – this does not support transparency and thus does not give me the visual effect I wanted – it also did not spike kernel mode time. The engineer then asked for research time; which I gladly granted.
Progress! An illusion that I was quickly disabused of when he called me back. "I cannot reproduce the problem here. Please upload your files so I can escalate this issue."
After the upload, the case went dead for nearly two weeks. Then I was called back by a new engineer. Clearly, the case had not yet been escalated because this time I was told that JPG and GIF are the standard image types that all web developers use.
This really angered me. Adobe Fireworks uses the PNG format natively! After arguing this point, she agreed to keep working on this issue. We recorded another movie of my desktop reproducing the problem repeatedly. We even downloaded the trial software for Dreamweaver CS5 just to test a different set of program files. What a waste of my time!
I generated a user mode dump of the Dreamweaver process from the Task Manager (a nice feature in Windows 7) and uploaded that to Adobe.
It has been 7 days since I last asked for an update (the Adobe support page promises follow-up in 24 hours).
Adobe technical support sucks!
In my previous post, I mentioned the disappointing performance of Dreamweaver CS5 while editing a site very similar in appearance to this blog page.
I like the aurora borealis look to the background and that you can still see that borealis behind the grey framing that holds the content of my blog. This effect is achieved by a single-pixel PNG graphic. As most web developers can tell you, it is possible to "stretch" a graphic to any given size. So this single-pixel grey image takes advantage of the transparency features of PNG and is stretched to make up the grey framing.
The framing itself is three <div> tags and the same PNG image is used as a background for each of them. When it is "layered" over itself twice, as in the postings content and right-side menus, it becomes a darker grey. But it still lets that borealis image appear through without obscuring the text.
I could not type text into the web site due to the performance issues with Dreamweaver. It took several dozen seconds for my words to render in the Design View. Interestingly, the Code View did not have any issues at all. That was an important clue.
I collected a Performance Monitor trace and capturing the Process and Processor objects while Dreamweaver was running. I noticed that as soon as I switched to the Design View of Dreamweaver after editing my Cascading Style Sheet to use the PNG image that the "% Privileged Time" for the Dreamweaver process spiked up to about 90% and held steady there for quite some time. You can see that spike in the picture to the left.
The "% Privileged Time" is also known as kernel mode time. Without getting too sidetracked, a Windows process has "user mode time" and "kernel mode time." User mode is the code written by the developers and kernel mode is calls made into Windows. So, to render my web site in Design Mode, Dreamweaver was making extensive calls into the Windows API.
This was not a problem with Dreamweaver CS3. So somewhere in the two versions since then, Adobe changed what they were doing within the Design Mode code. It was time to open a support case with Adobe…
One reason for my drop in posting this month is that I bought a new toy. I upgraded from my Adobe Web Standard CS3 to Web Premium CS5. I love the toolset around Dreamweaver for web work. Web Premium also gives me Photoshop and I was excited to have something new to learn.
I installed everything on my laptop at work and had a colleague walk me through some Photoshop settings and experiments. Amazing! I was blown away.
Then I installed CS5 at home and launched Dreamweaver on a local site I had begun in CS3. All my thrill and excitement evaporated. The performance sucked.
It sucked intolerably. An absolutely unusable product! What was wrong?
Of course, my career at Microsoft orbits the world of troubleshooting, so I began to dig in. You are – at this moment – looking at what caused the performance problem. My website was based off the same Cascading Style Sheet and graphics as this blog theme.
Little did I know, that I would end up facing the stress of calling Adobe Technical Support…
Many of the link problems with the tags, categories, post calendar and the comments appear to be fixed now.
The correction was in the Permalink settings for WordPress – I set them back to default and things started working. I am not sure how that lead to breaking things in the first place; however, for the time being I will be satisfied with a working blog.
Still To Do
- Setup RSS feed(s)
- Display my Flickr images
- Minor visual tweaks
It is obvious that I need to commit some additional time today to getting this blog looking just the way I want it to. Right now, the thorn in my side are the four columns in the footer of the page. Although I did manage to figure out how to edit the Blogroll, I cannot seem to remove the original default columns to add my own. This might require rolling up my sleeves and digging into the HTML and CSS code myself.
Later today, I’ll put real blog links into the Blogroll – at the moment, they are merely pointing to other websites. It is likely that most of blogs will point to SQL Server material; hopefully I can tweak that up further though and categorize.
The next big thing to do will be getting the RSS feed(s) to work properly.
Lastly, the “About” page doesn’t point anywhere! You will get the dreaded HTTP 404 error if you click that link. With a bit of luck, I can get that to link back to my website.