We Keep Coding

Process.Start() exits right away on Windows 7

Process.Start("d:/test.txt"); //simple .txt file works perfectly fine on Windows 8 onward but on Windows 7 (x64) it starts the process and immediately closes it.
I've already tried the following:
Calling through ProcessStartInfo and setting CreateNoWindow=true, UseShellExecute=true and Verb="runas" (though not sure why I had to set this one).
Tried attaching Exit event and it confirms that the process does start but it exits right away and I don't even see the Notepad window open for a blink of a second.
Edit: I've tried it with an image files and few other extensions and they open just perfect. Something wrong with just the .txt files (and/or probably other formats).

I was able to solve this bug just by changing build platform from AnyCPU to specifically x64 (my target machine is x64). This is strange but it solved the problem! Thanks Simon Mourier for this tip.

Its definitely an issue with file association. I have tried it windows 7 and it works fine. Try double clicking on the file and check if it opens in notepad, if it doesn't then configure it to open via notepad.Also you should check the exception that it throws,
If File association is missing then it will launch the Openwith dialog.
If it is associated with wrong program then you can change it manually.
If you want to find association type pragmatically then, I would suggest looking at this answer.
How to I get file type information....

You're saying your code is working fine in other OS and other file formats even in Win 7.
Let's try following checks to verify if things are correct
Verify if notepad.exe is in path
Start -> Run -> notepad.exe should launch Notepad
Double click on a .txt file and see if it automatically opens in Notepad
Verify if Process.Start("notepad.exe") starts an instance of Notepad
var process = Process.Start(file used in step 2); and verify the returned process info in the debug mode and see if says the newly created process is still running or not.

I've had this happen on Windows 7 before. It's likely that your Path environment variable has become corrupted. The maximum number of characters that can be used in the Path variable is 2047. Installing many executables on your machine can overflow the Path variable. Here is a SO discussion that shows some ideas to get around it:
How do you avoid over-populating the PATH Environment Variable in Windows?
If you just need to get notepad running again quickly, you can modify the Path environment variable and just put the system location to Notepad at the beginning of the variable. (ex. "c:\windows\system32\notepad.exe").
And if you're not sure how to modify your Path variable, here is a good how-to:
http://geekswithblogs.net/renso/archive/2009/10/21/how-to-set-the-windows-path-in-windows-7.aspx

What about just using
Process.start("start", "d:\\test.txt")
or
Process.start("explorer", "d:\\test.txt")
or
Process.start("cmd", "/c notepad.exe d:\\test.txt")
If it still doesn't work, try using the straight shellexecute, as described here
Executing another program from C#, do I need to parse the "command line" from registry myself?
https://www.gamedev.net/topic/310631-shellexecuteex-api-call-in-c/

Detect when exe launched via Google Chrome Native Message Passing

I'm trying to retrofit an existing NPAPI plugin to use Google's native message passing technology. Since it's an existing exe, we already have some console behavior programmed in so that users can call our program from the terminal. Is there any way for us to detect, in a C# application, that the exe has been launched by Google Chrome for message passing? If we could do that, we could launch the message passing loop if we're called from Chrome but resume normal behavior if called from Powershell/cmd.
I've tried inspecting the command line arguments passed to the program when launched by Chrome, but there are none. Having a configurable option there would solve this for us, but as far as I can tell it's not possible. I haven't yet had a chance to inspect the current working directory in case it could also be used as an identifier.

Actually, yes, I believe it is possible.
When, for example, a C# console application is started as a native message client host, it is passed two arguments:
--parent-window=<number>
and
chrome-extension://<extension identifier>/
I think the second argument is probably the ideal one for determining that not only was it Chrome that launched the process, but that the specific extension you authored and intended to call it launched it!
Please make note in the above, the "<" and ">" are not literally part of the argument, and just used to denote the beginning and end of that part of the message, much like double quotes.
Alternatively, just have your extension invoke a script (.bat, .sh, etc.) that passes special arguments to your native host. This way you could pass specific arguments of your own.

The API doesn't support passing command line arguments, but your host process should be able to inspect its own parent process to determine if it was launched by Chrome or something else.

An alternative to checking the arguments as suggested by #aikeru would be to check for the existence of certain environment variables that were passed from Chrome to the native messaging host. My host has the following variables that seem to be specific to Chrome (found with Sysinternals Process Monitor):
CHROME_ALLOCATOR=TCMALLOC
CHROME_BREAKPAD_PIPE_NAME=\\.\pipe\GoogleCrashServices\S-1-5-18
CHROME_MAIN_TIME=13037817851797830
CHROME_METRO_DLL=0
CHROME_PRE_READ_EXPERIMENT=100-pct-default
CHROME_RESTART=Google Chrome|Whoa! Google Chrome has crashed. Relaunch now?|LEFT_TO_RIGHT
CHROME_VERSION=33.0.1750.117

C# How to to tell what process is using a file?

I am getting a pretty common, "The process cannot access the file because it is being used by another process."
Now I am nearly certain that the only process accessing this file is from code that I have written and I've been careful to use a using statement around accessing it.
But to be 100% sure, is there anyway to check this programatically when this error occurs?

There is also a small tool handle.exe in Sysinternals Suite that does exactly what you need. Use it from the command line:
handle.exe -a <filename>
Of course under Vista and Windows 7 this tool must be run elevated.

e.g. oh.exe from the Resource Kit and Process Explorer from sysInternals both show who is using what
Both of them use techniques not available in C#.

Windows Vista adds a new function, GetRunningObjectTable which you can use to detect which program has a file open. This only works in Vista+, and it only works when the application that has the file open actually implements supports for IFileIsInUse (e.g. Office supports it, but most 3rd-party apps probably don't).
Other than that, the usual way this is implemented is by opening each process, enumerating the file handles they have open and searching for the filename in question. This is pretty low-level, and would require quite a bit of P/Invoke to implement in C#, but it's not impossible.
It's usually easy enough just to open up Process Explorer and let it do the search.

c# program works from cmd prompt but not run separately?

I would post a snippet, but I honestly have no idea what part of my code could possibly be doing this. The program is sizable, I don't want to make you all wade through it. What kinds of things could possibly be the cause of this? Everything works perfectly when called from the command prompt: "readoo.exe". But when I click the exe in its file. . . "readoo.exe has encountered a problem and needs to close. . ."
this is intended to eventually be a scheduled task -> i'm worried, will it work?
i've never debugged, all i've ever used is notepad. I am learning, and feel that this strengthens my understanding of a project.
it crashes nearly immediately. there are no shortcuts, though the file paths are relative.
trying this method: shortcut -> properties -> shortcut -> Start In. I don't have a "shortcut" option
my program reads log files, parses, and creates 4 new files based on the found content
Microsoft Error Report says file not found. But how can this be? the files are there, albeit relative.

Take a copy of your project, and then start hacking bits out of it. When it no longer crashes, you've removed the bit causing the problem.
At what point does it fail when you double-click on it? Immediately, or only when you take a certain action?
You could also add a lot of logging to it, which could indicate where the problem is too.

This is probably looking for a dll that it can't find or is finding a different version from what it wants.
You could try Process Monitor or Process Explorer from sysinternals to see what dlls it loads when it does work and where it finds them.

Try putting a System.Diagnostics.Debugger.Break()call as the first thing in Main() and you'll be asked to attach a debugger - this should definitely show you what is different betweent the 2 invocations.

I would start with identifying what is different in the two methods of execution. Is there a shortcut modifying anything?
The starting directory?
The execution account?
command line arguments?

There are 2 things that it could be:
The current directory could be different when you click on the program or run from the command prompt.
The settings and path could be different when you click on the programe you are using the standard command prompt, are you opening the visual studio command prompt when you run the program from the prompt.

If your application relies on some file that should be on the same path of that exe, that can occurr.
You will have to change the properties of the exe (or shortcut to the exe) to "Start In" the directory where your exe is. For a shortcut, right click on the shortcut -> properties -> shortcut -> Start In.
I guess that is what I think could be the cause.
EDIT: Add a Console.ReadLine towards the end of your code to make it pause for you to see any exception thrown. That should help when you run it using windows explorer.

Put a try/catch around your code and output the exception message to the console in the catch block. That should give you some clues.

Open a folder using Process.Start

I saw the other topic and I'm having another problem. The process is starting (saw at task manager) but the folder is not opening on my screen. What's wrong?
System.Diagnostics.Process.Start("explorer.exe", #"c:\teste");

Have you made sure that the folder "c:\teste" exists? If it doesn't, explorer will open showing some default folder (in my case "C:\Users\[user name]\Documents").
Update
I have tried the following variations:
// opens the folder in explorer
Process.Start(#"c:\temp");
// opens the folder in explorer
Process.Start("explorer.exe", #"c:\temp");
// throws exception
Process.Start(#"c:\does_not_exist");
// opens explorer, showing some other folder)
Process.Start("explorer.exe", #"c:\does_not_exist");
If none of these (well, except the one that throws an exception) work on your computer, I don't think that the problem lies in the code, but in the environment. If that is the case, I would try one (or both) of the following:
Open the Run dialog, enter "explorer.exe" and hit enter
Open a command prompt, type "explorer.exe" and hit enter

Just for completeness, if all you want to do is to open a folder, use this:
System.Diagnostics.Process.Start(new System.Diagnostics.ProcessStartInfo() {
FileName = "C:\\teste\\",
UseShellExecute = true,
Verb = "open"
});
Ensure FileName ends with Path.DirectorySeparatorChar to make it unambiguously point to a folder. (Thanks to #binki.)
This solution won't work for opening a folder and selecting an item, since there doesn't seem a verb for that.

If you want to select the file or folder you can use the following:
Process.Start("explorer.exe", "/select, c:\\teste");

You're using the # symbol, which removes the need for escaping your backslashes.
Remove the # or replace \\ with \

You don't need the double backslash when using unescaped strings:
System.Diagnostics.Process.Start("explorer.exe",#"c:\teste");

You should use one of the System.Diagnostics.Process.Start() overloads. It's quite simple!
If you don't place the filename of the process you want to run (explorer.exe), the system will recognize it as a valid folder path and try to attach it to the already running Explorer process. In this case, if the folder is already open, Explorer will do nothing.
If you place the filename of the process (as you did), the system will try to run a new instance of the process, passing the second string as a parameter. If the string is a valid folder, it is opened on the newly created process, if not, the new process will do nothing.
I don't know how invalid folder paths are treated by the process in any case. Using System.IO.Directory.Exists() should be enough to ensure that.

Use an overloaded version of the method that takes a ProcessStartInfo instance and set the ProcessWindowStyle property to a value that works for you.

You're escaping the backslash when the at sign does that for you.
System.Diagnostics.Process.Start("explorer.exe",#"c:\teste");

System.Diagnostics.Process.Start("explorer.exe",#"c:\teste");
This code works fine from the VS2010 environment and opens the local folder properly, but if you host the same application in IIS and try to open then it will fail for sure.

Ive just had this issue, and i found out why. my reason isnt listed here so anyone else who gets this issue and none of these fix it.
If you run Visual Studio as another user and attempt to use Process.Start it will run in that users context and you will not see it on your screen.

Does it open correctly when you run "explorer.exe c:\teste" from your start menu? How long have you been trying this? I see a similar behavior when my machine has a lot of processes and when I open a new process(sets say IE)..it starts in the task manager but does not show up in the front end. Have you tried a restart?
The following code should open a new explorer instance
class sample{
static void Main()
{
System.Diagnostics.Process.Start("explorer.exe",#"c:\teste");
}
}

Do you have a lot of applications running when you are trying this?
I encounter weird behavior at work sometimes because my system runs out of GDI Handles as I have so many windows open (our apps use alot).
When this happens, windows and context menus no long appear until I close something to free up some GDI handles.
The default limit in XP and Vista is 10000.
It is not uncommon for my DevStudio to have 1500 GDI handles, so if you have a couple of copies of Dev studio open, it can eat them up pretty quickly. You can add a column in TaskManager to see how many handles are being used by each process.
There is a registry tweak you can do to increase the limit.
For more information see http://msdn.microsoft.com/en-us/library/ms724291(VS.85).aspx

System.Diagnostics.Process.Start("explorer.exe",#"c:\teste");
Just change the path or declare it in a string