MS Visual Studio Update Killed T-Clock x64

[Stoic Joker]

Okay bear with me on the topic title as I wasn't really sure what to call this issue. But here's a thumbnail sketch of how i got here.

About 2 years ago I created a 64bit version of TClock which Kazubon originally wrote back in 1995.

I had a catastrophic motherboard/disk array failure that resulted in the loss of most of my code library, including the as released code for T-Clock32 & T-Clock x64.

I work for a living so it has taken some time to (try and) put Humpty Dumpty back together again.

I still have an intact ("Working") copy of a pre-release build of the project that I'm trying to get back off the ground with ... But the 64bit code doesn't run correctly anymore (e.g. it crashes the shell).

Now... I'd been asuming that part of the project file was damaged, but the copy I'm working with was on my web server at the time of the crash and therefore not involved in the crash. The compiled binaries included with it run fine. problem is when I recompile the project, the binaries are slightly larger than they should be (were) and the crash the shell instead of displaying the clock.

My version of the code was originally developed on an XP x86 machine and tested on an XP x64 machine. Now I'm running Vista x64 with all servicepacks & updates, and it appears that therein lies the issue.

As a measure of last resort, I created an XP x86 VM, installed MSVS 2005(RTM), updated nothing, and compiled the code. It ran perfectly. ...Which now begs the question...Why?

So far I have run the following (compile & run) tests:
Vista x64 SP1 & MSVS2005 SP1 with all updates applied - Compiles fine (is 1KB larger) and crashes the shell
Vista x86 SP1 & MSVS2005 SP1 with all updates applied - Compiles fine (is 1KB larger) and crashes the shell
XP x86 SP2 & MSVS2005(RTM) with no updates - Compiles fine (is the "right" size) and Runs fine.
XP x86 SP2 & MSVS2005 SP1 with no other updates - Compiles fine (is 1KB larger) and crashes the shell

Notes:
All combination of the 32bit(x86) version of the project compile and run fine.
The TClock project consists of two files tClock.dll which contains the ShellHook code and always compiles to the same size, and Clock.exe which compiles to either 152KB (working code) or 153KB failing code.
Both T-Clock32 & T-Clock x64 use a single common source code pool that allows the project file (and some conditional #define statements) to define if it will be compiled as 32 or 64bit code.


So, does anyone have a clue why one of the changes in MSVS2005 ServicePack 1 would cause a 64bit shell hook to fail?
I'll gladly make the project file available to anyone willing to help.

Thank You,
Stoic Joker

[Eóin]

A possibility is that there is a memory access bug (buffer overflow would be one guess) which is in fact present in all compiled exe's/dll's but a slight rearrangement of the binary by VS 2005 Sp1 means it is only actually doing serious harm there.

[Stoic Joker]

If the program was just straight crashing on load, I'd agree but it isn't. (Perhapps I described the issue badly). The program doesn't actually crash (x64 only) until it's forced out of memory (e.g. task manager-> end process tree) ...Which is actually kind of normal behavior for a shell hook being treated that way.

The program typically inserts the hook in the Windows Clock window erases the contents, and then inserts its own. Most of this is still happening. Only the last (inserts its own) part fails, which makes it impossible to get the (modified) clock's context menu and exit the program gracefully. If the clock is left to run (albeit clocklessly) the shell is perfectly fine, it's only the forced exit that "kills it".

Not to mention that the x86 version still runs fine which gives me the impression this is a 64bit only issue. Either way I need help in resolving this as I've not a clue how to even get started addressing it.

[f0dder]

I don't really have any ideas off top of my head, but I'm going to try and take a look at the stuff a bit later - I hope the crash also happens on XP64, otherwise debugging is going to a bit harder (although I do have Vista64 on my laptop)

[Stoic Joker]

It should; currently the only available shell I can afford to keep crashing is a RDC to my Server 2003 x64 Domain Controller (They're both based on the same code branch).

[Stoic Joker]

You guy's forgot me, didn't you.

[f0dder]

You guy's forgot me, didn't you.

-Stoic Joker (February 07, 2009, 08:55 AM)

Sorry, been pretty busy IRL - but I have a couple of days off now, so I should have time to look at it after work today, if I'm not too trashed

[Stoic Joker]

That's cool (I gota work for a living too)

I haven't had time to explore Eoin's input in depth either. Altho I did spend quite a bit of time (back when) tracing through the buffers to make sure I wasn't going to blow myself out of the water by adding:
#define _CRT_SECURE_NO_DEPRECATE 1

to the main header file (Don't yell at me I know it's bad...). There were too many (200+) depricated API warnings when I compiled it to fine the (other) errors I was looking for ... So I put that part on the To-Do-Later list (mayhapps it is haunting me?).

I do appreciate your looking into it for me

Stoic Joker

[wetsmellydog]

Hey Stoic Joker,

There is a gentleman who has been kind enough to post your old programs due to your issues.
They can be found here;

http://www.greggdeselms.com/tclock.html

"This is a special, temporary web page created so that persons who have been given its URL (or who happen to stumble onto it via Google or some other search engine) will be able to download the version of Stoic Joker's T-Clock system tray clock replacement utility that I just happen to have on my computer, which I downloaded from his site back in 2006 or 2007. As of this writing, his web site  has been down for a while, and so no one has been able to download any of his truly outstanding versions of the venerable freeware T-Clock utility..."