Going 64bit:: leader or last one ?

64 bit platform has been reserved for 'big system" during a long time, when a lot of memory or cpu math were needed. With the time being, it's now so common that any pretty current desktop /laptop can do 64 bit. Nevertheless, 64 bit keep used only when it's mandatory, as it's still not so obvious on what it brings. Microsoft put some pressure by supporting Exchange 2007 on 64 bit. As it's stalling, they add more pressure by supporting Windows 2008 R2 only on 64 bit.

Why do we put the brakes on 64 bit ?

• A lot of software editors don't offer a 64 bit version of teir products. So it will works, but through Wow64 to emulate 32 bit anyway.
• Drivers must be signed by Microsoft. Why ? Around 2 blue screen (BSOD) on 3 are due to bug in drivers. To be signed, a driver must pass some tests, to be considered as stable. You can even make these tests yourself by launching verifier. This is as simple as doing Start / Execute / verifier. Even if you are an admin and not a developper, you will want to use the developper scenario. Many checks are available:

You shouldn't activate these tests on all drivers, as you may not be able to boot again. Except if you are really confident on your drivers quality (or already signed)!

Some editors provide a 64bit version, but all processes are still 32 bit. It's just that their 32 bit version still works in 64 bit.

Apple, with Snow Leopard, finally make the big bang choice: they only provide a 64 bit version. iMacs and others won't have this new version, and editors will have to povide correct 64 bit versions.

Should you be a leader on 64 bit deployment ? I don't think so, except if you truly need it, as with all new technology. But, deploying 64 bit in 2009 doesn't make you a leader anymore! Ok, you still have to manage changes on your teams, a lot on the dev team. As i always recommend, think big but start small. Use new project to learn on 64 bit impacts.

Cygwin1.dll and the mysterious version problem

As i started computing on Linux/FreeBSD, I still my little habits to parse logs (awk/sed/cat/sort/uniq…).
Recently, cygwin, a Unix shell port on Windows, stopped working:

So there is a trouble with cygwin1.dll. Indeed, i am also using another tool, John the ripper, that has been ported to Windows through cygwin.
But the DLL for JTR is much older than the one included in my cygwin. Starting in the reverse order gives same result, except it's JTR that crash for same reason.

Procmon from Sysinternals confirm that each program load its own cygwin1.dll. But cygwin doesn't read the DLL file, instead it just do a "Load image". JTR does it, but after reading the DLL file:

Process Explorer helps me to point out the root cause. Cygwin1.dll uses a section type handle that have the same name, anyway which version of the DLL is used.

Handles for JTR:

Handles for cygwin itself (bash.exe)

I could confirm the diagnostic using a feature of Process Explorer: close an handle inside a process:

The cygwin shell is now working while JTR is also running. The thing is that i don't what could be the consequences in JTR:

The case of the driver leaking handles - Marvell Yukon Service

I noticed that one of my process, rundll32, was leaking handles thanks to Process Explorer, a sysinternal tool. Rundll32 is a Windows hosting process, so it's the process hosted inside that is leaking. Hopefully Process explorer says who is behind by just overlaping the cursor:
So the hosted service is Marvell Yukon Service (yksvc), used by my network card. To find what sort of handle is leaking, i added the lower pane inside Process explorer by pressing crtl +L. Scrolling down, i found a lot of mutant, always on the same object, \BaseNameObjects\NetCfgWriteLock. All new handle are highlighted in green, so i found out that it keeps opening a new handle every second or so:
A right click allows to get its property:
As Mark always recommend, i checked my driver version, which is a bit old:
A newer version is available on the Marvell support page, so i decided to give it a try.
Before doing the driver update, i used perfmon on my system to check the handle behavior before and after the upgrade. It confirmed that the bug is now resolved:
Thanks to mark tools & tutorial, this problem is gone :)