Expression Web 3 Crashes Often

That the original Expression Web crashed often in my ordinary use of it is documented separately. It would have been naive to expect that upgrading to Expression Web 3 would bring much change. Indeed, I feared the worst when I crashed the program within hours of purchase, as described on the page Expression Web 3 crashes when enabling Manual Style Application while no page is open, but the coding error responsible for that one was as easily found as it may have been easily written. Prepared to excuse that crash as unfortunate but known and avoidable, I set about putting the new software to use for this website.

For the first couple of months, my use of the new version was barely more than occasional and anyway very light, but once I started using the new version as often and as heavily as I had been using the original version a year before, the crashes started to come thick and fast. Clearly, I use the product in some way that doesn’t get tested much. Perhaps it’s my use of subsites (which, though supported in the user interface, are obscure enough not to have any mention in the product’s help files). Perhaps my subsites have too many pages or I sometimes have too many open at once. Perhaps I use the Include Page feature too heavily and ought not nest the inclusions. Who’s to know, but I am anyway disinclined to generosity to the writers of this software: as demonstrated on the several pages I have yet written about Expression Web bugs, this software has numerous problems just of basic functionality even when working with the initially opened blank page of a fresh installation. This really is wretched software, especially considering that it comes from the world’s largest manufacturer, who most has the resources to get basic things right. They don’t look to be trying very hard for Expression Web.

Of course, I didn’t buy Expression Web as a case study in defective software. I bought it as a tool for the real work of writing up results (of other research) for publication at a website. When Expression Web crashes, I sometimes attach a debugger to see if the crash is amenable to a quick explanation. But since most of the crashes occur deep in a very large DLL for which I don’t even have public symbols, it’s usually very clear very soon that the time needed for investigation would be seriously disruptive of the work that I bought the program to help me with. The best it seems I shall be able to do is catalogue the crashes, so that at least some public record can be found by anyone who wonders if they are alone in finding that Expression Web crashes often.


All the crashes that I record on this page occurred in the ExpressionWeb.exe process, running on 32-bit Windows Vista SP1. The ExpressionWeb.exe version is 3.0.3813.0, from Expression Web 3 SP1.


Arguably the largest component of Expression Web is the DLL that acts as the Microsoft Expression Web Editor. Its name, FPEDITAX.DLL, recalls its origins as the Microsoft FrontPage Editor.

Crashes have been reported from FPEDITAX at offsets 0x0001050E (nine times), 0x00084C6F (twice) and 0x001239A6 (twice).

The repeated crashes at offset 0x0001050E tend to occur while opening a file. My feeling is of some connection to my use of Include Pages, particularly as preparation of new Include Pages was part of the work at the time. The crashes were sometimes not long preceded by Expression Web’s failure to resolve one or more Include Pages. For the record, four of these crashes occurred during a few days while working on the page ApiSetSchema and its few dozen companions which share content from a dozen Include Pages.

The crash at offset 0x001239A6 recurred on the same day, after a reboot, just while typing text in the same set of files as for the first occurrence. Additionally, over several days of working on these particular files, the program restarted seven times. By that I mean that it looked hung for a few seconds but then recovered (with a new position on the taskbar). I believe that those are yet more crashes, just not ones the user is alerted to. A pattern is developing for these: they seem most likely when switching to Design view from Code view. The files concerned are distinctive for having very large tables. The cells contain nothing but text, never more than a few short lines, but there are thousands of rows. For an example, see NTDLL Exports. Even without crashing, something clearly is very wrong with how Expression Web (and FrontPage before it) handles tables: in Design View, the simple act of typing in so large a table can take seconds for each character.


Three crashes have been reported from Protocols.dll, at offsets 0x0005EA17 (twice), 0x0005EA1A and 0x0006B0E3. Curiously, two of these occurred while Windows Error Reporting was running because of a fault in another ExpressionWeb.exe process. (In Expression Web 3, the windows for multiple sites, including subsites, are each in their own process.)

Crash Dumps

After complaining at the Microsoft Connect website, asking what Microsoft offers that is at all constructive for users who find its software defective, and including to offer that I’ll do the debugging myself if Microsoft will lighten the load by publishing relevant symbol files, I have been asked by Microsoft (in the person of Jim Cheshire) to capture crash dumps so that Microsoft can do the debugging. Quite why Windows Error Reporting never itself captures such files to send to Microsoft when Expression Web 3 crashes is a mystery to me. (It did save them for some crashes of the original Expression Web, though I believe it never went so far as to send them to Microsoft.) Still, given that someone may look at dump files for these crashes, it’s no trouble to create them for each new crash and link to them from here.

Faulting Module Offset Dump File
FPEDITAX 0x001239A6 3rd June 2010 - first occurrence (321KB)
3rd June 2010 - second occurrence (316KB)
Protocols 0x0005EA17 16th June 2010 (326KB)
FPEDITAX 0x0001050E 17th June 2010 - first occurrence (266KB)
17th June 2010 - second occurrence (257KB)
18th June 2010 (265KB)
19th June 2010 (263KB)