This isn't strictly a programming question, but hopefully someone here has the knowledge to help me.
Running Vista x64, the "Open File With" dialog takes forever to appear when trying to open a file with unknown type.
To be specific, the prompt giving the choice between "Use the web service to find the correct program" and "Select a program from a list of installed programs" appears immediately, but there is about a 10 second delay between pressing OK here and the next window (with a list of installed programs) appearing.
The same delay is present when I run "rundll32 shell32.dll,OpenAs_RunDLL" from a command line.
I'm guessing that this is not common behaviour, because I find it incredibly annoying, and I couldn't find any mention of it anywhere.
So..does anyone have any ideas what it might be? Or what I could do to try and find out?
VonC could be correct.
Read this article:
http://blogs.technet.com/markrussinovich/archive/2005/08/28/the-case-of-the-intermittent-and-annoying-explorer-hangs.aspx
You should use process explorer to watch the stack when you initiate the action. You should be able to tell what sort of operation is timing out.
Download process explorer here:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
You could check if you do not have have network connection declared (net use), or more generally any network paths which may be used by your list of program listed to "Open File With".
If a network path is unavailable, a 'timeout' delay can affect the GUI responsiveness, especially if that GUI must explore/list those paths.
Related
I have two Access databases that I'm opening on the same computer. In one, running this in the immediate window works as expected (opens Notepad):
Shell "notepad.exe"
In the other, I get this error instead:
Run-time error '5': Invalid procedure call or argument
I have not been able to come up with any shell command that will run successfully in that second database. No matter what, I get that error.
What is going on here? Could there be a security setting coming into play? Or perhaps one is an older version?
Edit - More Info
When I go to the definition of Shell in the malfunctioning database, it goes to VBA.Interaction.Shell.
I get the correct IntelliSense tooltip for Shell.
I tried VBA.Shell "notepad.exe" and VBA.Interaction.Shell "notepad.exe" without success (same error).
Here are the references that are checked in both databases:
Decompiling did not help.
The culprit was our anti-virus software! UGH!
Why did it work in one database and not the other then? I'm told that years ago, anti-virus exceptions were made for my computer for the one database but not the other.
I recommend that any others who encounter this problem check their anti-virus logs/policies. Also, running the database from another computer with different policies in place might shed some light on the issue faster. In this case, when I used remote desktop to log into a server, I was able to call shell successfully.
I'm trying to create a piece of software that will not be susceptible to bots. Is there a way for me to code into a program a way to check in the operating system for a process just like it and then put in a shutdown mechanism if it is recognized. Think of something like netflix where if one tab in chrome is running netflix, a second tab being opened will display an "oops" message. Is there anything like this for something that does not run on a web browser? What should I be looking into?
Thanks in advance
There can be plenty of solutions; the first coming into my mind are:
1) your program checks for existence of a particular file; if the files is not found then the program continue, otherwise your programs know that another instance is running and thus can terminate immediately. If the file is not found, your program creates it and then delete it before exting.
2) you can use an operating system call or an o.s. utility program to know if another instance of your program is running (e.g.: in linux, the command ps)
have fun
Any help with this problem would be fantastic. I appreciate all contributions!
Let us say I'm running a daemon that is observing the behaviour of the app that has keyboard focus. I have it's PID and process name. Is there any way I can see what files that application is accessing?
I'm programming in Objective-C, Cocoa and C.
Thanks!
EDIT:
Sorry, I should have clarified. I want to be doing this programmatically from the daemon. Thanks
There's a command line tool called lsof that shows you every file that's open and what program has it open. You could look at its source, then do the same thing periodically.
I don't think you can intercept reads and writes, though—not without using DTrace, which requires root powers.
Use the Activity Monitor (from /Applications/Utilities).
Pick your process - press the Inspect button.
Choose the Open Files and Ports tab.
So I'm looking here and I see the command line switches. http://mono-project.com/Command_Line_MoMA
This is what I see as the total amount of switches from the site:
MoMA.exe --nogui --out C:\app\momareport\report.html C:\app\myapp.exe
One thing I see is the submit.xml going to a place I don't want during my automated build. Since it is a generated file, I want to change where it goes. Is there a switch for that?
Also, what are all of the switches for it?
If there is not a switch for moving the submit.xml to a reporting location, please consider it for future versions.
EDIT: The argument --help does not work. I tried that and a host of others to try to get some dialog from MoMA on the command line. I'm on Windows to help alleviate any confusion.
Those are the only command line switches supported by MoMA. You can see the code here.
"MoMA.exe --help" does not work because MoMA is compiled as a winforms application so that the command window is not shown. As a result, MoMA disconnects from the command window, and therefore things like Console.WriteLine will not work.
To answer your actual question, there is currently not a way to change where the .xml file gets put.
You might want to try:
MoMA.exe --help
On Linux, there should also be a manpage.
If you can't find the feature, and want to submit it to Mono, you'll want to go via the Bugzilla page.
I have a Window Forms application (using clickonce installation, running on a terminal server) that occasionaly ends up with a thread that appears to be running in a tight loop. The user doesn't know this happens as the app continues to run as expected. Also I have determined that I can kill the problem thread without any apparent affect on the app.
I can use Process Explorer to find the instance of an app with the problem and can isolate the thread with the problem but haven't found any way to look into the thread to find anything that would help me determine what is causing the problem. Does anyone know of a way to some additional information about a thread, like maybe strings, that would help me zero in on the issue?
Thanks,
Dave
Haven't tried this myself but "Process Monitor" claims it "shows real-time file system, Registry and process/thread activity"
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Hope this helps.
You should be able to attach Visual Studio to the running process to get more information. Provided the .pdb files are included with the application and you have source code for the avialable version you should be able to use the Threads window combined with pausing / stepping through to see just what the code is doing.