Just installed FF for eval and am getting this dialog whenever I do anything in FF:
For security purposes, this program will not run while system debuggers are active. Please remove or disable the system debugger before trying to run this program again.
Okay, I have no idea what this is talking about. I have no other development environments loaded on this system (Win XP SP2). What's up with this, then?
Thanks
A bit more info. This message pops up only when the mouse hovers over a file in the New Project dialog.
Also, googling the message points to this being a problem with the SoftIce system, which I have not (knowingly) installed on my system. So that begs the question: What obscure interaction is being highlighted by FF and whatever control is being used in the filelist of the New Project dialog?
I can honestly say that I have no idea what would cause this problem. FireFly uses the Armadillo software protection system so I assume that it is Armadillo that is detecting an installed debugger.
Actually, I would assume that Armadillo would display the message prior to you being able to do anything in FireFly. That is, I expect that you would get the error message before you entered the FireFly environment.
Having said all that, maybe it has something to do with the WinXP SP2. I understand that service pack contains many, many security type patches/fixes for Windows. The File Open dialog is hooked by FireFly. Maybe that is causing problems with Windows. I doubt it because hooking a common dialog is well documented and allowed by Windows.
Try downloading the example posted by Borje Hagsten at http://www.tolkenxp.com/pb/ofntempl.htm It also uses a hooked dialog. Does it cause the same message for you ????
Borje's dialog runs just fine. When I hover the mouse over a file or directory, it pops up the tip with info about the entity.
In FF, when the New Project dialog is open, I can do everything... except when I hover over a file when the "Existing" tab is active. Instead of a tip with the file info, I get the error dialog. Also, the same error occurs if I use the Open Project dialog.
This is not inherent in SP2. I have access to another system that is also running XP SP2 and FF works fine on that system. Unfortunately, I can't run FF/PB there because it is not my system.
Whatever the interaction is, it seems to be localized to generation of the file info tip that appears in the file open dialog.
Interesting. I run Win2K for development. Hopefully another FireFly user can verify the error as well. In the meantime, I will reinstall WinXp on my old laptop.
Paul, I haven't seen this problem before, and just now could not trigger it. Tried both the initial dialog that appears on FF startup, and also using the Open Project dialog from the File menu. The popup "tip" shows up just fine whether I hover over a project file or a folder.
I'm using FF 2.50 on an XP (sp2) system.
-- tom
I don't believe this is an XP SP 2 issue. This is an interaction between FF and something else. As I've never installed FF before, and as FF is the last thing I have installed on this system, and since the message is leaving no tracks as to its origin, it will be difficult to determine where the interaction is.
I have used FF on three different machines all with XP PRO SP2 and this has not surfaced. Before I moved to this machine the previous one had "TONS" of stuff installed before and after FF.
Several things you might try to isolate the problem and test at each step.
1) Turn off the XP Firewall.
2) Turn off any other Firewall and virus protection.
3) Run SpyBot Search and Destroy to make sure nothing funny is on your machine.
4) Go to www.sysinternals.com and download AutoRuns and see what is starting when you boot Windows. They also have other nice free stuff like a RootKit revealer. Google anything that seems strange and things not Microsoft signed that AutoRun when you boot. Be careful on the Google results to make sure you understand what is being said if something looks like it should be disabled. AutoRuns will let you turn something off but not remove it and put it back easily.
BTW -- The guy that found the Sony RootKit problem is the owner of this site.
5) Un-install FF and reinstall in a different directory (reboot after un-install before reinstalling).
Ahhhhhh ---- Windows ----
Good luck.
Yeah, all the usual bull associated with using Windows :-) And people wonder why it is I run all my servers on Unix and Linux.
First I think I'll wait until Paul has a chance to query Armadillo about this. I'm sure it's not the first time this has cropped up.
The major differences, Paul, between the two systems I've tried is that one runs MS Office and the other runs Open Office. It is the latter that is having issues. Also, the latter (problem) system runs VLC media player. And of course, Powerbasic. Other than that, the working system has a ton of additional software that the failing system does not. All firewalls, security software and settings, etc, are the same on both systems.
I've had a similar (don't recall the message, as it was back sometime in May this year) experience with an application called StrongSearch, and it turned out to not like the hooking done by another application (PS Hot folders 1.1) that I'm not willing to get rid of. Thus I tossed out StrongSearch before I could evaluate it. Not that easy for you though, as you definitely don't wanna miss out on FireFly's splender!
Try killing off one by one process in TaskManager and see if you can identify any conflicting application other than a Windows component.
Okay, I killed everything not Microsoft using Task Manager. Still have the problem.
So I killed even more using Process Explorer, including Microsoft stuff. Still have the problem.
So I used msconfig and put the system into diagnostic mode, which is about as plain vanilla as you can get. Still have the problem.
Since everything else I kill off in diagnostic mode causes the system to reboot, I'd say the root cause is very deeply rooted.
As much as I'd like to give FF a look it is not a critical need for me at this time. I'll be tossing it for now and will see if v3 resolves this issue. In the meantime, maybe Paul and Armadillo can find and fix the problem. In Texas we used to shoot the armadillos...
Quote from: grimblefritz... In Texas we used to shoot the armadillos...
:D
No worries. I will pop a note off to Silicon Realms to see if Armadillo is the cause or if it is something specific to FireFly.
You should still be able to open FireFly projects via the "Recent" tab or the Most Recently Used projects list on the File menu. You could also associate the ".prj" file extension to be opened with FireFly and then you could use Windows File Explorer to open the file.....
I did a search on Armadillo's private support forum and there was a post about keyboard hooks "sometimes" causing a problem. Here is part of the quote from the developer:
Quote
Armadillo doesn't have any problem with subclassed windows... hooks, it can sometimes have a problem with, depending on how they're implemented. (Cracker tools like to hook certain functions to make cracking easier.)
I will send a more detailed support request directly to the author.
Just wanted to say I have no problems here with XP SP2 Pro and running the latest ZoneAlarm which monitors everything including hooks, etc. Having this also gives me a little extra knowledge on confirming that it is hooks. The open dialog didn't report hooks..probably because I never use it much and after 5-10 times of running FF I gave it full permissions. However, I did use the editor options a lot, like when you right click in the text editor and select to change the options. If you go to the Keyboard tab FF makes a keyboard hook. If this gives you problems then the hook issue is confirmed.
Sorry, no good. I can open the editor options and navigate the keyboard tab w/o issue. It seems definitely localized within the tip info of the file dialog.
Hmmm, I didn't think hooks would be it either...especially since the hook Paul mentions really isn't much and doesn't do hardly anything if at all with tooltips. Perhaps a search about the message and tooltips or the TTM_... messages they send requesting info. Winspector reports it is sending TTN_GETDISPINFO and TTN_SHOW, along with LVM_GETITEMW and WM_USER+3245. When the tooltip fires. The listview in a common dialog also appears to be custom drawn.
If you cannot find the issue you might consider getting a new hard drive then use Ghost or some other tool to make an image back up. Then switch out your primary drive with this "clone" and then reinstall Windows back on top of itself. Normally it will keep all of the settings for installed apps.
If you like the thrill of taking risks you can do it without the backup on your main drive but it may become "way too thrilling" if you break Windows for good.
FireFly is clearly one of the best development tools on the planet. Yep -- it has a few quirks and is not as mature as VB or other products but in combination with PowerBASIC it helps you write code the way it should be done. I have an app built with FF that is nearly 300,000 lines of code. With a little work I could probably get the EXE on one floppy. Try that with VB.
FireFly is likely NOT the root cause of your problem but did manage to make it surface.
Good luck.
LOL -- Sounds like some people have time on their hands.
This system was installed less than three months ago and has only a bare minimum of software installed. Just what it takes to do its job. If FF can't work properly in that environment, then there's really nothing to remove and/or do without.
Although FF itself is probably not the root of the problem, it is fairly clear that Armadillo is. And were it not for FF Armadillo would not be on my system. For that matter, even if it is not Armadillo, I have no issues anywhere else except with FF. So as far as I'm concerned, this is a FF issue. Plus, this error is not all that uncommon in the general population, just uncommon for FF. It is not like I've stumbled on something that has never been seen before elsewhere.
No need to sell me on FF/PB either. I threw VB out eons ago. In fact, if it weren't for PB I wouldn't code for Windows at all. Even with PB, I find the Windows platform so horrendous that I do relatively little Windows coding anymore anyway. My bread and butter is in Linux (too bad PB has never delivered on the oft hinted PB/Linux!) Mainly I want to see how FF stacks up against the latest PB Forms and EZGUI. Any way you slice it, without a GUI builder -- whether PB/Forms or EZGUI or FF -- I would further limit my Windows programming to PB/CC.
Hopefully this is something Paul can sort out. From what I saw before I removed it, FF is a terrific product. I've used Jellyfish and Cheetah for several years, so a top notch product from Paul is not a surprise. However, copy protection schemes IMHO are just problems waiting to happen, and I almost never rely on software that has a copy protection scheme. FF might be the exception -- it did look really good -- but not if the copy protection scheme doesn't work on my system.
This is the response that I just received from Silicon Realms support. It doesn't really provide any new information unfortunately. :(
Quote
Hi Paul,
We don't recall any problems specific to hooked dialogs. One thing you mention is that this is only happening to one person... if that's the case, I would assume that this is a difference between their system and everyone else's, almost certainly related to some kind of software that that user is running (maybe something that tries to "improve" the dialog in question).
I hope that helps!
Regards,
Denis
As has already been pointed out, you don't have anything special installed on your system so we're still in the dark.
You use Linux and Windows... any chance that maybe you're running VMWare or similar type of software? Just taking a stab in the dark.
Nope, not on this system. I do have one system with vmware, but it is a linux system. I don't even have a Windows vm running on that one.
Not aware of any dialog enhancing tools either. I generally run a straight Windows load, and then add only the essential apps and utilities. Tends to work better that way. Usually :-)
I did a text search for a subset of the message text. Came up empty, so it is probably either encrypted or in a compressed file. Was hoping to at least tag the culprit file.
Maybe you could drop some trace info into the New Project file dialog and send it? Crumb up the screen all you want, whatever it would take to identify what/where exactly it comes from.
Did they by any chance mention if they had any ability to identify exactly what/which debugger they think they've found? The only ones I'm aware of would be the debug modes for IE and .NET -- both of which are disabled. And if those were the problem, then more folks than just me would be affected.
Your call. If you want to chase it down, I can load and run a hacked version with traces for you. Like I said, FF looks great, and I know your other work so I'm sure it is great. Don't mind spending some time to help you find this -- might help someone else down the road. You've got my email, so we can take this out of forum if you'd like, at least until we suss out something.
Best thing I see at this point since I imagine Paul doesn't want unprotected code out there is perhaps a app created with the protection that has various common dialogs, etc as FF has them and various other test cases to expose what this is doing. Other things are checking the Event Logs in the Admin tools on the machine giving the errors for possible reports and/or other errors that may only be noted there and could shed light on the problem. Other possibilities are what is loaded when the error occurs- Services running (Admin Tools again), Event Logs also contain messages stating what services and such load too, Registry Run apps- both in Local Machine and Current User, and Start Menu Startup folder apps...plus any others loaded manually or by other means.
I know this may sound like a lot, but if I were having an error no one else experienced I'd want to figure out why...no telling what it could be and better safe than sorry if it is something on your machine that you don't want. Sounds like you are worried about FF causing things too- "And were it not for FF Armadillo would not be on my system". Armadillo isn't "on" your system, it is just in the exe file. All it amounts to is code inside the exe to decompress the file and protect against debuggers running with standard win32 API...so if that causes problems then something is on your machine to compromise the protection...this may or may not have been put on the machine by you. I too am one to always be on guard with things on my machine and monitor everything, including FF. I even have a resource viewer that can view compressed exe's and nothing is in there but the basic icons, etc.
Also, if you have seen the other thread...it appears a user is having problems with hooks and such with themes turned on...maybe try it with both themes on and off to see if results differ.
I too would want to know why my system is different than all of the others that use FF. One thing I have learned, especially with a security focus, is there are lots of hidden and ugly things that can and do go on inside of Windows. Some accidental, some bugs, and some put there on purpose by some malware or accidentially by an errant program.
You like UNIX --- so do I --- for starters no registry. If you want to un-install generally just RM the directory. Graphics are not "wormed down deep inside" the Kernal that was required to get the performance in the "old days". The list goes on but sadly Windows "owns" the desktop so we all have to live with it.
My suggestion for reloading Windows on a Ghosted disk was to try and eliminate any "funny" stuff. If it works you will never know why but you can "move on".
This sounds like root kit stuff to me if you have not loaded any known but different software. You can't see any difference from the outside because the problem is deep down inside of Windows.
Did you load a Sony CD recently? ;-)
Just one opinion.
Nope, no recent loads since the original install (of the system, from bare metal) in October. And definitely nothing from Sony -- I don't think I even own anything by Sony ;-)
As to Armadillo being on my system or not, well, it is there in some form. Just because it's not loaded as a separate package, it is still "on there". It is part of Armadillo, Paul didn't write it, I gather its inner workings are black box in nature -- so it is kinda on there.
As to walking backwards through startup folder apps, registry loads, etc -- when you use msconfig to put the system in diagnostic mode, it strips out almost everything that is not Windows essential. The running tasks list gets very short in this mode. Since the problem was still in evidence in diag mode, with nothing much running, it would be pointless to piecemeal through the stuff manually. It is apparent the interaction is in some fairly low level, core stuff, probably some updated DLL. The next step, if you really wanted to dig through it, would be to check the DLL versions of what is running in diag mode and see what is different from a "clean" load, and start swapping at that level. That's a pain!
I'm not suggesting Paul put out unprotected code. (Okay, so I sorta am -- copy protection sucks and isn't all that effective imho -- but it does give the 'bad' hackers a purpose in life I suppose.) That aside, what I WAS suggesting was that Paul simply put in some debug-like traces in the file dialog to help identify exactly what triggers the error dialog. That is definitely not unprotected code -- that would be annoying as hell code! :) But it might narrow the search.
Patiently waiting for Paul to weigh in. This is definitely not something to interrupt the holidays over :-) It won't upset my apple cart if this takes a good while to sort out. Heck, I'm still waiting for an email confirmation from PB of the updates I ordered on Sunday...
I will create a small application that uses FireFly's "Open' dialog (the one with the hooked dialog). I will then post it in both protected and unprotected exe's. Hopefully I can get that done today. Lots on my plate today but I will give it a shot.
Okay, I uploaded a simple zip file that contains two EXE's. One is protected with Armadillo and the other is not. Try both to see what happens. The code is the sample PBNote source with the FireFly new open dialog added to it.
http://www.planetsquires.com/files/newopentest.zip
Okay, downloaded and tried both apps. The unprotected one works just fine. The file tip pops up as expected. The protected one yields the same alert dialog (btw, that means both the message and the alert sound) and never does pop up the file tip -- which is the same as I see in FF.
I think that means we can conclude it is an Armadillo interaction. The question is: Interaction with what? Is there nothing Armadillo provides that would allow a developer to identify the conflicting debugger?
Thanks for testing the code and confirming that there is still a problem.
Quote from: grimblefritzIs there nothing Armadillo provides that would allow a developer to identify the conflicting debugger?
I will send a message to support to see if they can help (maybe they can produce a debug version that will display the debugger name).
Here is part of the message that I just sent to Armadillo support:
Quote
So, my question to you, can you protect the "unprotected" sample EXE
in the above download with a debug version of Armadillo that will
display the name of the suspected debugger???? We want to try to track
down what is the offending piece of software on the user's system. He
swears that his system is just a plain, vanilla, WinXP Professional
installation (with SP2).
Hmm, this is just plain odd. One other thing to track down is if it is the common dialog or the tooltip. Do any other tooltips work in FF like the icons/buttons in the tool panel where you add the controls? Maybe a tester app with a window containing tooltips and one with some kind of keyboard hook or something and tooltips. Might try different code too like the code I posted for balloon tips with both cases too to see if there is a difference in standard and balloon tips, etc. To me it is odd why, if there is an app/virus/infection, it would be monitoring common dialogs/tooltips. Lots of data could be "harvested" that way...but what/why they are doing it or what it is after would be a mystery worth solving.
IsDebuggerPresent is probably at least one of the APIs they are using, but it appears to be only boolean. DebugBreak, FatalExit, or OutputDebugString may help in figuring out what is loading on the system. If it is loaded with FF chances are it is loaded with all apps and you could write one to return if one is present then try breaking/exiting to it or writing a string that may be output somewhere and lead you to where it is.
Yes, all other tooltips in FF seem to be fine. It is only in the New Project and Open Project dialogs that there is an issue.
Just for kicks I opened several other apps -- Explorer, IE, VLC Media Player, PB/Win 8, PB/CC 4, etc -- and file tips appear as they should.
It is definitely localized to FF/Armadillo.
Good news! I have identified the source of the conflict and removed it from the system. It seems the DiskView plugin for Google Desktop Search -- which I tried and didn't like and forgot was there -- was the problem.
As DiskView is also shareware, I've suggested to Paul that perhaps it was a conflict caused by another "anti-piracy" system such as FF. At the very least, there is now a known problem that can be referenced in the future.
DiskView also appears to load its DLL when in diagnostic mode, even though the interface is not loaded. That made it a bit harder to nail down.
Thanks to everyone for suggestions and additional brain power, and especially to Paul for going above and beyond by creating and sending test apps.
Now, off with me to do a decent eval of FF.
Merry Christmas and Happy Holidays to everyone!
Cool! That is great news that you tracked down the problem. I sent an
email to Armadillo support advising them of your discovery.
:)
Awesome...BTW, were these test apps what found it or your own "brainpower"? If apps, the apps and perhaps code would be a good addition for my tools. Maybe even a possible addition to FF itself to detect at startup and report the problem before the protection software causes errors, etc over it. It is always good to find problems before they occur so they aren't difficult to track down.
Unfortunately (for the purposes of automated gotcha checking) it was good old-fashioned brainpower. I had already been down the road of killing all apps, starting in diag mode, etc. So I decided to start looking for DLLs that might still be running, even though the "app" was not.