[RESOLVED] Process.Start System32 Directory Error

So I'm using a listview and a button to launch the selected program the user chooses. Though I'm having an issue with snipping tool and msconfig but with notepad it launches fine. I noticed that it launches perfectly on a 32-bit system but on my 64-bit system it doesn't...

This works completely fine BUT...
If lstUtilities.SelectedItem = "Notepad" Then
If IO.File.Exists("C:\Windows\System32\notepad.exe") = True Then
Process.Start("C:\Windows\System32\notepad.exe")
Else : MessageBox.Show("This program is not installed in your computer or is installed in a different directory", "Error", MessageBoxButtons.OK, MessageBoxIcon.Error)
End If
End If

This ONE doesn't
If lstUtilities.SelectedItem = "Snipping Tool (Windows 7)" Then
If IO.File.Exists("C:\Windows\System32\SnippingTool.exe") = True Then
Process.Start("C:\Windows\System32\SnippingTool.exe")
Else : MessageBox.Show("This program is not installed in your computer or is installed in a different directory", "Error", MessageBoxButtons.OK, MessageBoxIcon.Error)
End If
End If

So as this one...

If lstUtilities.SelectedItem = "System Configuration (Windows 7)" Then
If IO.File.Exists("C:\Windows\System32\msconfig.exe") = True Then
Process.Start("C:\Windows\System32\msconfig.exe")
Else : MessageBox.Show("This program is not installed in your computer or is installed in a different directory", "Error", MessageBoxButtons.OK, MessageBoxIcon.Error)
End If
End If

So what happens? DO you get an exception? Does the screen tap-dance across the screen? We need a bit details other than "It doesn't work", if you don't mind.

Both SnippingTool and MSConfig worked fine for me on 64-bit Win8.

I mean that the Else : MessageBox.Show("This program is not installed in your computer or is installed in a different directory", "Error", MessageBoxButtons.OK, MessageBoxIcon.Error) shows up and nothing happens as I want it to be if the file does not exists BUT it is there I even checked it myself, it is not hidden, same directory paths and names. Launching manually works perfectly fine as I mentioned before. If I removed Else : MessageBox.Show("This program is not installed in your computer or is installed in a different directory", "Error", MessageBoxButtons.OK, MessageBoxIcon.Error) I noticed that the program does not freeze or show any kind of error, there's something blocking it from checking whether "msconfig.exe" or "snippingtool.exe" exists. I tested it on 2 other laptop's both with no antivirus/anti malware turned on, still doesn't work.

I can't help but notice that you have exactly the same error message in every case (surely you need to include the program name at least?) Are you sure that this is actually not related to your selections rather than the programs. If the file is there and the right bit of code is executed there is no reason for it to fail. You'd be far more certain of what is happening if you used selected index rather than item. One tiny typo and the selection is never made.

I'm certain that my list is correct because after this
If lstUtilities.SelectedItem = "System Configuration (Windows 7)" Then
If IO.File.Exists("C:\Windows\System32\msconfig.exe") = True Then
Process.Start("C:\Windows\System32\msconfig.exe")
Else : MessageBox.Show("This program is not installed in your computer or is installed in a different directory", "Error", MessageBoxButtons.OK, MessageBoxIcon.Error)
End If
End If

The next program on the list is WinRAR

If lstUtilities.SelectedItem = "WinRAR" Then
If IO.File.Exists("C:\Program Files\WinRAR\WinRAR.exe") = True Then
Process.Start("C:\Program Files\WinRAR\WinRAR.exe")
Else : MessageBox.Show("This program is not installed in your computer or is installed in a different directory", "Error", MessageBoxButtons.OK, MessageBoxIcon.Error)
End If
End If

And that works perfectly on all three machines, no errors when I try and click the launch button. It's just msconfig.exe and snippingtool.exe that has this problem. I have many other programs on the list with the same error case window popup (in case "name.exe" does not exist) and they all launch fine, it's just those two programs that don't and I wonder why...

Are you compiling your program to 32 bit? When a 32 bit program is run on a 64 bit Windows OS, then attempts to access certain system folders are redirected to their 32 bit counterparts.

"C:\Windows\System32\notepad.exe" would be redirected to "C:\Windows\SysWOW64\notepad.exe" and "C:\Windows\System32\SnippingTool.exe" would be redirected to "C:\Windows\SysWOW64\SnippingTool.exe".

If you check in the C:\Windows\SysWOW64 folder you will see that notepad.exe is present but SnippingTool.exe is not there.

There's a lot of information about this on the Net. Search for "SysWOW64" or "windows 7 filesystem redirection". A couple of quick examples:

http://www.samlogic.net/articles/32-...6-syswow64.htm
http://blogs.sepago.de/e/helge/2008/...fferent-part-7
http://msdn.microsoft.com/en-gb/libr...=vs.85%29.aspx

Quote:

---

I'm certain that my list is correct because after this

---

Huh? What does that prove? Part A of my code must be right because part B works is a complete non sequitur. It must be raining in Tokyo because it's raining in London?

You have a long list of If Statements. What happens if none of them is true?

If lstUtilities.SelectedItem = "System Configuration (Windows 7)" Then

If the item is, due to a typo, actually "System configuration (Windows 7)" say, clearly this condition is not met and presumably none of the others will be either. So then what?

My point was that this badly structured pile of conditionals means that you can't actually be sure even where the error is coming from (to say nothing of endlessly repeating code unnecessarily). You simply cannot guarantee that the error is not procedural and nothing to do with either of the two programs that fail to launch. The idea that there is some kind of block on finding the files is frankly preposterous.

Firstly, let me say that I hope that this thread has demonstrated that you need to provide a proper explanation of your problem. Just saying "it doesn't work" is never enough. We can't read minds so you need to actually tell us what happens.

As for the issue, when File.Exists didn't work as expected, did you bother to read the documentation for that method? It would appear not. Is it not an obvious step to use the Help menu when you need help? Is it not an obvious step to read the instructions when something doesn't work as expected? Apparently looking for yourself is something that doesn't even occur to far too many people. This is from that documentation, which is simple press of the F1 key away:

Quote:

---

Return Value
Type: System.Boolean
true if the caller has the required permissions and path contains the name of an existing file; otherwise, false. This method also returns false if path is Nothing, an invalid path, or a zero-length string. If the caller does not have sufficient permissions to read the specified file, no exception is thrown and the method returns false regardless of the existence of path.

---

Now, I'm no expert when it comes to file and folder permissions so I'm not 100% sure why you'd be allowed to execute the file but not read the folder but that's what you need to look into.

Quote:

---

Originally Posted by dunfiddlin

Huh? What does that prove? Part A of my code must be right because part B works is a complete non sequitur. It must be raining in Tokyo because it's raining in London?

You have a long list of If Statements. What happens if none of them is true?

If lstUtilities.SelectedItem = "System Configuration (Windows 7)" Then

If the item is, due to a typo, actually "System configuration (Windows 7)" say, clearly this condition is not met and presumably none of the others will be either. So then what?

My point was that this badly structured pile of conditionals means that you can't actually be sure even where the error is coming from (to say nothing of endlessly repeating code unnecessarily). You simply cannot guarantee that the error is not procedural and nothing to do with either of the two programs that fail to launch. The idea that there is some kind of block on finding the files is frankly preposterous.

---

If none of them is true then the Message Box appears saying that they do not exist. I'm certain it is not a typo as I have checked clearly on the List Box "System Configuration (Windows 7)" is the same as I have on my code page If lstUtilities.SelectedItem = "System Configuration (Windows 7)" Then....

Quote:

---

then attempts to access certain system folders are redirected to their 32 bit counterparts

---

Not when you're using absolute filepaths they aren't. Process.Start("C:\Windows\System32\SnippingTool.exe") isn't going to go searching anywhere but in the folder it's been given.

Quote:

---

Originally Posted by ybriK

If none of them is true then the Message Box appears saying that they do not exist. I'm certain it is not a typo as I have checked clearly on the List Box "System Configuration (Windows 7)" is the same as I have on my code page If lstUtilities.SelectedItem = "System Configuration (Windows 7)" Then....

---

So, it produces exactly the same error message but you are certain that it can't possibly be the case? Properly debugging by stepping through the code from an appropriate breakpoint would tell you immediately whether you have cause to be certain. Actually just putting a breakpoint in the relevant part of the If clause and seeing whether it's ever reached would tell you. The blind belief that you can't possibly have made a mistake will not.

Quote:

---

Originally Posted by dunfiddlin

Not when you're using absolute filepaths they aren't. Process.Start("C:\Windows\System32\SnippingTool.exe") isn't going to go searching anywhere but in the folder it's been given.

---

I will say it again: when running a program compiled to 32 bit on a 64 bit Windows OS, attempts to access certain system folders are redirected to their 32 bit counterparts.

It is true for System32 and some of its sub folders, Program Files and certain Registry Keys.

Maybe a little more research and a little less absolute negativity.......

Quote:

---

I will say it again: when running a program compiled to 32 bit on a 64 bit Windows OS, attempts to access certain system folders are redirected to their 32 bit counterparts.

---

Even if what you think you're saying is right (which it isn't in this context) what you actually say doesn't make any sense. Where would the 32 bit counterpart be found other than in System32?

But if you believe that repeating something makes it truer, I will say again Process.Start uses absolute filepaths when absolute filepaths are given precisely so that it is possible to specify the launch of a program which is other than the one that is found on the current Windows path. I'm well aware that the 64 bit system has a whole set of different default paths but that is completely irrelevant in this case! A little less research and a little more practical experience maybe? Absolutely!!

OK! I have solved the problem since I have a 64-bit machine all I had to do was change the configuration build to 64-bit architecture... Why didn't I thought of that in the first place. Anyways thank you for all the contributions and the links really helped as now I know what SysWOW64 is really for. Also I didn't even need Process.Start("C:\Windows\System32\SnippingTool.exe") it was just Process.Start("SnippingTool.exe").

Process.Start("%Systemroot%\System32\SnippingTool.exe") and Process.Start("%Windir%\System32\SnippingTool.exe") just gave me 'System.ComponentModel.Win32Exception'

It's all good now.

Quote:

---

Originally Posted by dunfiddlin

Where would the 32 bit counterpart be found other than in System32?

---

SysWOW64. Were you not paying attention?

Quote:

---

Originally Posted by dunfiddlin

I'm well aware that the 64 bit system has a whole set of different default paths but that is completely irrelevant in this case

---

From ybriK's code:

Code:

---

If IO.File.Exists("C:\Windows\System32\msconfig.exe") = True Then
Process.Start("C:\Windows\System32\msconfig.exe")

---

The second line is never reached because the redirection occurs in the check for the file's existence. Your absolute paths are absolutely irrelevant.

Quote:

---

Originally Posted by dunfiddlin

A little less research and a little more practical experience maybe? Absolutely!!

---

Please feel free to go forth and practice some :)

I tested this in win7 64bit:

Code:

---

Public Class Form1

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        MsgBox(IO.File.Exists("C:\Windows\System32\notepad.exe")) ' = True
    End Sub

    Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click
        MsgBox(IO.File.Exists("C:\Windows\System32\SnippingTool.exe")) ' = True
    End Sub

    Private Sub Button3_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button3.Click
        MsgBox(IO.File.Exists("C:\Windows\System32\msconfig.exe")) ' = True
    End Sub

End Class

---

+ this:

Code:

---

Public Class Form1

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        MsgBox(IO.File.Exists("C:\Windows\SysWOW64\notepad.exe")) ' = True
    End Sub

    Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click
        MsgBox(IO.File.Exists("C:\Windows\SysWOW64\SnippingTool.exe")) ' = False
    End Sub

    Private Sub Button3_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button3.Click
        MsgBox(IO.File.Exists("C:\Windows\SysWOW64\msconfig.exe")) ' = False
    End Sub

End Class

---

@.paul. Did you compile to x86 or x64? Try both.

Just for giggles, try testing:

Code:

---

Process.Start("C:\Windows\System32\SnippingTool.exe")

---

under both options.

Quote:

---

Originally Posted by Inferrd

@.paul. Did you compile to x86 or x64? Try both.

Just for giggles, try testing:

Code:

---

Process.Start("C:\Windows\System32\SnippingTool.exe")

---

under both options.

---

yeah that makes a difference