Strange problem with context menu shortcuts

Help & Support
1

This is going to sound weird, but...

I just rebooted the system for quite banal reasons (GDMFSOB Adobe updates), and when I tried to use one of my context menu shortcuts to start a "dos prompt" in a standard folder, instead of the application starting as it usually did, I now get my text editor displaying a blank text file called "C:\Program"

Now, the actual application that shortcut linked to is (without any quotes):

C:\Program Files (x86)\JPSoft\TCMD\TCMD.exe

Other shortcuts referring to a similar folder and application :

C:\Program Files (x86)\JPSoft\4NT8\4NT.exe

suffers from exactly the same problem, but only in Opus!

Now, I can assure you that I have NOT done anything to either of those applications, nor their folders, nor anything about them in at least a year.

I have also made no changes to DO in the time when I last used the menu items (yesterday) and today, and I've certainly not edited any of the shortcuts.

There have been no changes to any default application executions, no changes to my profile, and definitely no changes to anything explorer-related (that I'm aware of, anyway).

I've not touched any registry keys, nor anything else related to Opus or the two applications involved here!

I verified that both the shortcuts are listed and displayed and entered correctly in the context menu items, and they are - but for some reason, they no longer work!

FYI, I can run those applications from other shortcuts elsewhere on the system - for example, from the start menu, from Workshelf (Winstep extreme UI enhancement) and from explorer.exe's context menu.

The last time this happened to me, it was because some stupid shareware POC tried to create C:\Program as a folder because the inbred developer didn't know how to handle spaces in filenames (just this year, in fact). Bit I've double-checked, and there's no such confusing folder that could be tripping up Opus (I hope!). Having said that, because this is an x64 OS, there are separate folders for x86 apps (\Program Files (x86)) and x64 apps (\Program Files), but Opus has never had an issue with that before now.

If anyone has any ideas and/or suggestions, I'd be very happy to hear from you!

2

A-HA!

I was wrong, but at least it was for the wrong reason. And it's a good example of how a simple thing can really cause havoc with windows (apart from logging in, typing, saving, printing, opening.....) and many, many otherwise quite sensible applications.

This behaviour was triggered by some application that created a 0-byte file called "Program" in the root of my boot drive (C:).

When I was testing with explorer, sure enough, any time I tried to execute any application in the C:\Program Files (x86)\ folder (but NOT in the C:\Program Files folder, which threw me at first), windows seems to grab the smallest matching pattern in the root of the folder I'm trying to execute the application from, and instead treats that file as though I double-clicked on IT, instead of a valid installed application!

So when I click on (or execute as a fully qualified path plus app name from a command prompt) C:\Program Files (x86)\MyFolder\MyFile.exe, windows tries to execute C:\Program, which then automatically kicks off my editor, which I've configured to handle all unknown (*. nothing) file types. And it gets passed a single string parameter of "C:\Program", which it interprets as a text file (which is infinitely safer than any other fallback I know of, particularly because Textpad handles most files (legal text or not) extremely gracefully).

I've been hit by this a couple of times in the past 2 years, but at least this time it happened less than a month after the problem occurred before the next reboot, so I can now search for whatever the hell created the file at 2:13 PM yesterday. The hunt's afoot!

If I can find the app that caused this in the first place, I'll try and post a followup here.

3

Found it. Sigh.

Turns out JPSoft's Take Command V8+ and 4NT V8++ and TCI V2+ all experience.... slight... er... problems - when killing running scripts (btm files) in the integral debugger. The debugger totally freaks out and loses control of the batch execution thread, and there's all sorts of nasty things it does when it starts trying to execute partially-overwritten batch lines.

Mea culpa, mea maxima culpa. The app I was trying to run had caused the problem that stopped it (and the rest of windows, give or take) and couldn't recover.

So, despite my unflagging admiration for these tools (after all, I've been using them since DOS days), they do occasionally have a 'bite'. Given the sophistication and complexity of their internals, I'm not surprised, but I wish I'd caught it BEFORE I posted.

Hope this helps anyone else suffering from the same bizarre problem!