Using Windows XP Professional SP3 with all patches installed (minus a few recent ones, but the bug already exists for quite a while.)

I have MUSHclient running on my pc in a themed environment (plain windows theme, no windowblinds or some other crappy program). Now I connect to this computer using my laptop. If the connection settings say I do NOT want themes, MUSHclient will crash upon connecting. If I keep the themes setting, MUSHclient has no issues.

So MUSHclient chokes rather harshly if the theme setting gets changed. I'm not sure if it happens if you manually turn theming on or off, but that's not a usage scenario I care about either ;)

Could you look into this Nick? I just lost a fair bit of buffer that I still wanted to do some things with. :(

I gather you need XP Professional to get the remote desktop? I don't have that, nor do I want to pay heaps of money to get it.

A quick Google for << +"remote desktop" +crash +themes >> reveals about 93,500 hits, some of which seem relevant, in that other programs also crash with remote desktop in use. One person fixed the crash by removing (or updating, I'm not sure which) some other utility called RightClick.

It is hard to say what part of MUSHclient might be crashing here. Is it on actually opening a world file, or the program itself? If you view both PCs at once, if possible, is it possible to see how far MUSHclient gets (eg. does its main window appear)?

I don't think there are any egregious bugs in MUSHclient, after all it works on virtually every version of Windows from 95 upwards (if you install more recent DLLs under 95), and works without crashing - generally - under Wine for Linux. So it isn't too finicky with operating system versions.

I've read about some 'hackish' methods to get remote desktop working on Home in the past, copying dll's and stuff from Terminal Server.

The crash to reproduce is simple and as follows:

1) Have MUSHclient open while working on the PC itself.
2) Connect using a secondary PC. In the Extra Options, have Themes turned off (I only leave Bitmap Caching on). This way the Visual Styles are stripped and everything looks like W2000 and below.
3) The moment the connection passes authentication, MUSHclient pops up with an error. Or more precisely, the Visual Studio Just In Time debugger has nothing it can do and waits for me to click on OK before MUSH itself is forcefully killed.

It -could- be a factor that MUSHclient tends to be running on my leftmost monitor, which is secondary (thus I think the pixel region it is in is in the negatives horizontally speaking). But without the Themes being disabled MUSHclient keeps working 100%, so it is unlikely to be the related.

Reason why I want it to work with Themes off is because it increases by about ~30-50% in responsiveness over my laggy wireless that I've noticed, which is a real improvement.

If you don't mind my suggesting it, the fact that MUSHclient works on Windows 95 / 98 / ME / 2000 / XP / Vista and under Parallels and VMware Fusion on the Mac, plus under Wine on Linux, however crashes when using Remote Desktop, suggests to me a bug in Remote Desktop and not MUSHclient.

I have always tended to code cautiously, and not use undocumented features that "seem to work" which usually come undone when operating systems are upgraded.

The fact that it is related to themes is also strange, as MUSHclient doesn't, as far as I know, use themes in any way.

What I suggest you do is, first, try running with the /wine option, which disables some stuff that used to make it crash under Wine (like OLE automation startup).

Failing that working, I suggest going back and trying earlier versions, with a view to seeing which version crashes, compared to which one doesn't. Then looking at the release notes we might see that introducing, say, DirectX sound, or miniwindows, can be related to the problem. Virtually all old versions are still available here:

Either do a binary search (start in the middle and jump left or right as required), or simply start at version 1.04 and work your way up, preferably using versions known to be stable (which is indicated by a long gap before a new release). For example: