Be safe: rid yourself of MSXML4

Last week there was a post which finally helped me emerge from the shrouding mists of confusion on MSXML versions. After reading this, I was finally put at ease about which versions are which, and which to use.

Now, apparently, there is a zero-day exploit on MSXML 4. But, according to the well timed post above, we really shouldn’t be using MSXML 4. In fact, Adam made it clear that MSXML 6 is the one to use, if you need MSXML 4 functionality:

MSXML4 was a predecessor to MSXML6 but hasn’t ever shipped in the operating system.  MSXML6 is a significant step forward in terms of reliability, security, W3C and System.Xml compatibility, and it also has support for native 64-bit environments.  Right now we are investing much more heavily in MSXML6 and MSXML3 and we’re encouraging our customers to move to 6 when possible and 3 when necessary.

So, I recommend you kill MSXML 4 from being used on your machine from IE. You can do this with the registry, by setting what is known as the "kill bit". Here’s how you do that from the command line (forget the .reg file approach MS outlines in the workaround).

reg add "HKLMSoftwareMicrosoftInternet ExplorerActiveX Compatibility{88d969c5-f192-11d4-a65f-0040963251e5}" /v "Compatibility Flags" /t REG_DWORD /d 0x400

Of course, this will break sites which use MSXML 4 – but they shouldn’t be doing so. Kindly write them and ask them to redo this bit, pointing to the above clarification on MSXML.

Filed under: Administration

Development performance hack

Got a laptop? Do development? Mind wander between rebuilds and the app recycle/JIT and page display?

 

Mine too… I haven’t eliminated it, but I’ve found a setting which may keep me from getting 30km down the road of a day dream before IE draws the page.

 

<disclaimer>Warning: this will ruin your life if you follow this advice. Every bad thing that can happen, will. I am not responsible for you trashing your machine because you didn’t read and understand this.</disclaimer>

 

Also, don’t do this if you are running Windows Server, unless you do it in reverse. Look at the TechNet entry for more details.

 

In the registry, under the HKLM hive, open the SystemCurrentControlSetControlPriorityControl key and locate the Win32PrioritySeparation value (should be the only one in that key). Change it to 0x01 hex.

 

The full description of why this works to help your background services be more responsive on your dev box is rather lengthy so I won’t repeat it – merely link to it. Basically, though, it changes the unit of time (quanta) the scheduler gives to process threads depending on whether they have a foreground thread or not. 0x02 is the default and it gives foreground processes a quanta which is 3 times larger than the background process quanta. 0x01 reduces this to 2 times. 0x18 completely changes the scheduling to make it like Windows Server. Only if you are running XP (or 2000), though.

 

This allows IIS and the other server process you are using to build your app with relatively more time to get the work done. It may boost your services responsiveness when debugging things like web apps on the local machine.

 

Or not.

 

Let me know because I’m interested.

 

 

Filed under: Administration

Fixing VS.Net without losing your settings

Ever get a corrupted VS.Net 2003 installation? I have a number of times – must be all the SDKs and Add-ins I run.

 

One of the annoying things about the standard repair is that is munges all my user settings. This is bad. I like my settings, and it is quite a big hammer to use in a repair. I like to use a little more finesse. From my sys admin background:

 

msiexec /fom {E05F0409-0E9A-48A1-AC04-E35E3033604A}

 

Type this into a command window and Windows Installer will repair the files and machine registry settings of VS.Net without clobbering your user registry settings, where all your customizations are.

 

-r

Filed under: Administration

The popular C# Ping Utitility

UPDATE:

In C# 2.0 or later, just use the System.Net.NetworkInformation.Ping class:

static void Main (string[] args)
{
System.Net.NetworkInformation.Ping ping = new System.Net.NetworkInformation.Ping();
ping.PingCompleted += new System.Net.NetworkInformation.PingCompletedEventHandler(ping_PingCompleted);
ping.SendAsync("127.0.0.1", null);
}

static void ping_PingCompleted(object sender, System.Net.NetworkInformation.PingCompletedEventArgs e)
{
if (e.Reply.Status == System.Net.NetworkInformation.IPStatus.Success)
{
System.Diagnostics.Debug.WriteLine("Reply received.");
}
else
{
System.Diagnostics.Debug.WriteLine("Host unreachable…");
}
}

A google search will bring this article from C# Help up, since many have copied it: 

C# Ping Utitility

Ouch… this is a lot of code just to check if a host is up or not. I’m baffled as to why it isn’t in the framework. Perhaps I need to check out 2.0. In the mean time, the WMI Ping provider is more C# code friendly (notice I didn’t say better performance).

Here is some code for those who care not about sockets, performance or geek factor, but do want some clean, maintainable code:

private bool isMachineReachable(string hostNameOrIP)

{

string wqlTemplate = "SELECT StatusCode FROM Win32_PingStatus WHERE Address = ‘{0}’";

System.Management.ManagementObjectSearcher query = new ManagementObjectSearcher();

query.Query = new ObjectQuery(String.Format(wqlTemplate, hostNameOrIP));

query.Scope = new ManagementScope("//localhost/root/cimv2");

ManagementObjectCollection pings = query.Get();

foreach(ManagementObject ping in pings)

{

if( Convert.ToInt32(ping.GetPropertyValue("StatusCode")) == 0)

return true;

}

return false;

}

 

Filed under: Administration

Talking about Mapping ADSI Interfaces to the Network Management Functions

http://msdn.microsoft.com/library/en-us/netmgmt/netmgmt/mapping_adsi_interfaces_to_the_network_management_functions.asp?frame=true

Why is it that we have such a proliferation of network functions? LanManager is ancient history, by most accounts, yet we must still deal with the functions which are rooted in it.

Take enumeration of SQL Servers. There really isn’t a good way to do it in .Net. We can’t really rely on people to have published their SQL Servers in Active Directory (we could more easily if it was default on install, but it is an obscure setting). The best way is to wrap these old API functions with P/Invoke. Perhaps we’ll see this change in SQL 2005… anyone know?

Filed under: Administration