Console Application stopped working - c#

Is it possible for code to work perfectly on the Administrator profile and not work at all while logged in as another user?
I am building certain applications at work, and while developing, coded and tested while logged on as Administrator. Every application working normally.
Now before deployment, when I execute the same application, but now logged in with a specific user account, I just get the error "Console Application stopped working" etc etc. I have handled all possible exceptions with my own Message Box, but this error is something I did not expect?!
In the exe's, I tried changing setting to "Run as Administrator", no use!
Any help would be much appreciated. Thanks!
PS - There are certain FTP methods I reuse from another class. And by handling all possible exceptions, I mean, I would have a try-catch block for the FTP method, so in case of error encountered after deployment, affected user may call helpdesk and notify the exact error.

Well, its not the right way to go, but right click and run as Admin, works butter smooth. Should I go ahead and modify all executables to - Run as Administrator under Properties->Compatibility??
You should firstly investigate if your application does need Admin rights indeed. A few scenarios that I can think of where an App needs admin rights are writing to protected locations of the system, writing to registry (excluding the areas that the user has rights on). If you think that admin access is not needed, you could always seek other ways to make it work. For example, instead of writing to a protected location, create a directory for you application in the user's application data folder and write to that location.

When you launch the application, if you're running on I believe Windows Vista or higher(7 works this way for sure)
You can Right click on the application and click on Run as Administrator
And yes, Sometimes the application won't work if you're not running as an administrator. For instance, If it's trying to change files in a protected location.
There are other variances that can cause your program to not work, For me, "Console Application stopped working" normally means that you don't have the right version of the .net framework installed, but it can mean any number of things.

Related

ClrMD on another user's process

I have a .Net application that's reporting hangs in the Event Log. The events say "Application Hang" with no usable details to go by.
So I whipped up a C# console app that uses the ClrMD library. But the caveat is this application is being published as a RemoteApp. When I try to attach ClrMD to the users' process I get this error:
Microsoft.Diagnostics.Runtime.ClrDiagnosticsException: Could not attach to process. Error 0.
This is not surprising since I'm logged into the server as Administrator and they are in their own RDP session with a different user.
So then I decided to impersonate the user they are logged in as thinking if I run my ClrMD app as them, it will have access to that process. This gave me a different error:
Microsoft.Diagnostics.Runtime.ClrDiagnosticsException: Could not attach to process. Error 1008.
I can't seem to find any clues as to what 1008 means to know where to go from here. I realize I'm probably trying to do something that's not possible.
Has anyone gotten ClrMD to attach to another user's process?
If not, are there are debug tools out there that can attach to other users' processes?
If not, have people used ClrMD in within production and how would I know the app is hung to know when to trigger a ClrMD dump? Just monitor the UI thread in another background thread?
Had / have same issue. Running elevated as admin on a server via a console app didn't work. But it does work if run through PowerShell or Visual Studio itself with elevated permissions. The debugger requires Admin privs to connect live. Adding a manifest, etc didn't seem to help when running as a console.

Trouble running a .pkg program as an admin

At my work's sites, we have update packages that need to be run locally and synched with a small printer. These updates are of a .pkg format and when double-clicked should open a sync tool. Our sites are blocked to run any executables like this so a UNC prompt comes up and we need to enter our passwords and I'm looking for another way so we don't have to intervene everytime.
I've started a program that will open this file and run it under a domain admin account but the method process.start gives me the error "the specified executable is not a valid application for this os platform". To get around that, I've seen that I need to change the UseShellExecute property to True but doing this doesn't allow me to run it as a user so I'm back to the original problem.
Does anyone have any suggestions or alternative methods to achieve this?
Thanks in advance for any help!

Start WPF application on computer startup

I have a WPF application that I would like to be launched anytime the computer starts NOT when a user logs in. I know I can place the .exe in the startup folder, but I don't want that since a user has to login for that to be launched. I cannot use a Windows service, it's not an option for me.
Is there a way to start up an application once the PC starts up(or reboots), even before a user logs in? Any help is much appreciated.
You can't run an application without a user login. The only thing you can run is a Service, which I'm guessing from your question being about WPF that this is not what you want.
How about using the Task Scheduler? In Windows 7, there's a "Security options" section where you can set an option for a task to run whether a user is logged on or not. You can specify an executable file, and it'll start when Windows starts up.
(This won't scale though, if you're looking for an option when a user installs your software. For that, a service is the correct way to go... you may need to elaborate in your question why exactly you can't use a service.)

Getting program to run at start up from c# code. Setting Registry Run to 'true' doesn't work as well

I found this nice snippet of code online:
rkApp = Registry.LocalMachine.OpenSubKey("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run", true);
Which runs great but alas on windows 7 and vista I suspect, it crashes cause it doesn't have permission to write there.
So then I research (on stackoverflow of course) how to avoid this, quickest method:
rkApp = Registry.CurrentUser.OpenSubKey("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run", true);
Simple enough! Though there is two issues remaining. One is with both methods (on a XP Box that is), the program thinks its relative path is somewhere in the C:\windows folder now...so I.e. it won't find my path relative help files etc. The second issue is, on windows 7, my program won't startup until I log in. I want it to start up in the background if possible before anyone logs in.
Its a simple .exe that hangs out in the systray when its running. I didn't want to create this monstrosity of an installer to get around these admin and pathing issues.
I Think I would have to create it as a service (no clue how to do that) to get it to start up when the machine reboots before anyone logs in. Secondly to do that I am sure I have to figure out the admin privileges, and since I don't want to have to approve the program to run every time it starts up it sounds like I would have to figure out its admin privileges during install time, but alas no installer.
So just curious what routes I might take to get this to work. I can even suffer it coming up only after when the user logs in, but my current methods that work this way really screw up the pathing of my program since it tries to write stuff out to a new directory (not the one I originally started the EXE from). Etc...and I have no clue how to go about fixing that pathing issue.
It sounds like you need two programs here.
You can't have an application run in the system tray and run prior to login. The system tray doesn't "exist" until the user logs in and has a valid desktop.
The normal way to handle this is to make two programs. First, create a windows service that does the bulk of your work. This will run on startup, and be independent of any user logins.
Then, make a user mode application which uses IPC to communicate with the service. This can run on login, and "talk" to the service remotely, thereby providing your system tray requirements.
If you want your program to start as a service before anyone logs on, then it's going to need to be installed and run as an admin user. There's not getting round this fact.
There's a Microsoft Knowledge Base article on creating a service which should get you started.
There's a project template for a Windows Service installed by default in Visual Studio 2008:
"File > New > Project > Visual C# > Windows > Windows Service"

Launching a program using LocalSystem Service CreateProcessAsUser equivalent to double-clicking on the icon when logged in? [C#]

At my company we have a product which pretty much interacts with everything you can imagine... registry, databases, devices, etc... it is composed of many parts but the entire application is launched by a single executable (start.exe) which is responsbile for launching everything else - this is all legacy code and run under a USER account.
Currently this is launched as a STARTUP item (or by double-clicking on the desktop icon) in Windows, meaning when the user logins into the USER account the application (start.exe) automatically kicks off, under this account it has all the permissions it needs to run and everything has been fine for years...
Now comes the change - I have written a service (Serv.exe) that is running as LocalSystem - this service is responsible for updating the various software components of our product and works as follows:
- when the product detects an update it signals the LocalSystem service (Serv.exe) and then terminates itself
- Serv.exe will then perform all the updating
Now, after everything is done, the product (via start.exe) needs to be launched again automatically ... and this is where I need some advice ... what is the best way to restart the product (start.exe)?
Right now I use the LocalSystem Service (Serv.exe) and impersonate the USER account as follows:
- CreateEnvironmentBlock for the USER
- CreateProcessAsUser(start.exe) as the USER with the corresponding EnvBlock
- DestroyEnvironmentBlock
But is this really 100% equivalent to double-clicking on the icon in the USER account context? I need to ensure that everything is identical when it is either launched on STARTUP of USER or by Impersonation from Serv.exe (LocalSystem) - is there a risk involved? Will I still have the same rights/abilities with all databases? registry? device interaction? etc..
By loading the EnvBlock I seem to get everything I need but ... is this not a good way to do it...?
Kind of hoping for some guidance and advice from the pro's out there ...
Any help or hints would be much appreciated.
Thanks,
Update: Here is a post named: Launching an interactive process from Windows Service in Windows Vista and later. Which is exactly what you are looking for. It starts with:
The first thing you should do about it is that; don't do it. There are many limitations and bad implications and restrictions involved.
So first test if your current solution works. That depend on what the process is doing. If it is not involving user interaction. Or manipulating the current user session. Then you don't need this complex solution. If you need it, than good luck!
Before update: Its not 100% equivalent. Except authorization there are, in windows, sessions and, in each session, there are desktops. The process that is lunched from the service will run on the service session and desktop ( if the service has it). Depending on what the start.exe does, it may be important or not.
Look at the SetTokenInformation function.
Instead of launching the application directly as a "startup item" you could start a "launcher.exe" that then would launch your application. The service could then signal "launcher.exe" that another instance of the application should start after an update. Using this method you can't use the service to update "launcher.exe", but this executable should be very simple and hopefully not require any updates. Using this method would avoid all the pitfalls of trying to start an interactive application from a service.

Categories