I have developed an MSI setup with WiX, which includes a windows form application in c# .Net 2.0 framework and a windows service. When I run the setup, it gets installed successfully in all win 7, but fails in few win 7 and all win 8 machines by showing the privilege error ("Product: mysetup -- Error 1920. Service 'service displayname' (servicename) failed to start. Verify that you have sufficient privileges to start system services.") while trying to start the service at installation. Then I created an App.config file inside my windows service project and according to this link I wrote the following line which helped the setup get installed in all the win 7 machines till now, but no luck for any win 8 machine.
<runtime><generatePublisherEvidence enabled="false"/></runtime>
Regarding the service details, I have written the methods OnStart and OnStop inside my service. It actually starts the win form exe file at windows start-up. I have made the StartType property as Automatic at ServiceInstaller page and Account as LocalSystem at ServiceProcessInstaller page. I have also written the codes below inside WiX to install my service.
<ServiceInstall Id="ServiceInstaller" Type="ownProcess" Name="*******" DisplayName="******" Description="****** description" Start="auto" Account="LocalSystem" ErrorControl="ignore" Vital="yes" />
<ServiceControl Id="ServiceInstallerControl" Start="install" Stop="uninstall" Remove="uninstall" Name="******" Wait="yes" />
Presently, The setup and the windows service gets installed and runs fine in any win 7 machine, but fails in any win 8 and machine. Windows Event Viewer shows no detail but "msi setup fails".
Please note that, I have not added any ClickOnce or Publisher certificate yet for my application. I have planned to do it later, if that is not the reason for installation failure. How can I solve this or get the error details or debug this any way? Please help.
EDIT:
PhilDW's answer is very important to note. My win form application (.exe file) which my service tries to run, does not show up as a GUI but yes it actually interacts with the desktop and to achieve that I have followed and implemented this link. This is working fine on win xp and win 7 as of now and the service starts the win from app successfully whenever a user logs on. Not sure about win 8 or higher, hope this method does not get deprecated or blocked or barred by Microsoft Windows in higher versions for any security purpose (I mean, could this happen? what will be the solution then for interacting with desktop through LocalSystem windows service).
After Morten Frederiksen's answer I did the following. On one Win 8 (32bit) pc, I checked inside Windows->Microsoft.Net->Framework folder which contains 4.0 and 4.5 but no 2.0/3.0/3.5 exactly as told by Morten. Now, my win form app already contains the supportedRuntime entry in its App.config file as suggested by Morten, but no luck with the installation. So I added the same i.e.
<configuration>
<startup>
<supportedRuntime version="v2.0.50727"/>
</startup>
</configuration>
inside the App.config of my windows service (I think it's unnecessary) and ran the MSI after a rebuild, but the same thing happens, the installation rolls back displaying the same privilege error message. Then I tried to run my win form app manually. It shows the message "The app requires .Net framework 3.5. Would you like to download and install .Net framework 3.5 (2.0 and 3.0 included)". I clicked on "OK", it downloaded and installed the frameworks and ran the win form app .exe file successfully. Now that all frameworks are installed, I tried to reinstall my MSI and now it successfully gets installed and the service starts along with the app which actually does the desktop interaction now successfully.
So, Morten Frederiksen's answer helped me solve my case. It is clear now that in my case it is the absence of the required framework which caused the failure of the win form app which again caused the windows service to fail to start, which in turn caused the roll back of the MSI installation.
My guess is that you don't have .NET 2.0/3.0/3.5 installed on the Windows 8 PCs. By adding some configuration in your .config file you can enable .NET 2.0 applications on a system with only .NET 4.0/4.5 installed.
Here's how:
https://msdn.microsoft.com/en-us/library/jj152935%28v=vs.110%29.aspx
There are a few areas I'd look at, in no particular order. I'm assuming your forms app attempts to show UI, among some other assumptions.
You have wait=yes in the service startup. This causes Windows to wait until the service has started properly, the default wait time being 30 seconds. This means the service must get out of OnStart within 30 secs to show that it has in fact started ok. If there is a delay in there because of what's going on, you may find a timing issue could randomly cause it to finish within 30 seconds or not.
The second issue is probably more serious. I do not believe you can start a Winforms app from a service for the same reason that local system services can no longer interact with the desktop - it exposes a system account to the user's desktop for shatter attacks. This may be strictly enforced in Windows 8, so the Winform process dies and has a downstream effect on the service, depending how it's coded. This is relevant https://msdn.microsoft.com/en-us/library/windows/desktop/ms683502(v=vs.85).aspx
Finally, even if you could interact with the desktop there's a potential timing issue after reboots. If your service starts up and fires off the Winforms app, then this can happen before anyone has logged on, unless your code waits for a logon, because services run all the time when there is no interactive user, so your service is starting a Winforms app that tries to access a non-existent desktop. I don't know if you've handled this area or not.
I suggest you install your Winforms app and add a shortcut to the Start->Startup programs menu so that it starts when a user logs on. Then it can establish communication with the running service.
Related
I have the following Powershell code below that i've compiled into an executable (.exe) file and have packaged it into SCCM to push against several 100 users. I have setup the SCCM package to run as "Install as user" and not as an Administrator. The package successfully captures the data for users with Windows 7, but any user that has Windows 8/10 installed fails to capture the data I need.
I did a try/catch statement and get this error - "
Exception calling "GetActiveObject" with "1" argument(s): "Operation
unavailable (Exception from HRESULT: 0x800401E3 (MK_E_UNAVAILABLE))"
I'm trying to understand why the same exact code works perfectly on Windows 7 machines, but does not work on Windows 8/10. Is there a fix? I would like to avoid using "New-Object -ComObject 'Outlook.Application'" because i don't want to create a new Outlook process in the background (fear of corrupting user's running Outlook session). I need to run the Powershell code to capture the active running Outlook process. Please help. Thank you
$mail = [Runtime.Interopservices.Marshal]::GetActiveObject('Outlook.Application')
$name = $mail.Application.DefaultProfileName
output of $name is stored locally to a log text file.
Make sure Outlook and your app are running in the same security context - either both apps are running with elevated privileges ("Run As Administrator") or neither app is running as an admin.
I was experiencing similar symptoms. I don't know if this is your exact problem, but maybe my solution will help someone else who stumbles across this issue.
The following MS KB article mentions that Office applications do not register themselves in the ROT until the application loses focus (which is apparently "behavior by design"). If the application is not registered in the ROT, GetActiveObject will return the error you indicated.
In my case, the script was working reliably on Windows 7, but it only sometimes worked on Windows 8. For some reason, perhaps related to the versions of Office installed, different versions of Internet Explorer (which I used to launch the Office apps) or maybe changes to Windows itself, I experienced different default window focusing behavior on Windows 8. As soon as I manually clicked on the Office app in my Windows 8 tests, the script started working.
To solve the problem, I just inserted a call to focus the Office application window before making the GetActiveObject call, which made the operation completely reliable on Windows 8.
I have a portable app that isn't stealth. And by stealth, I mean:
"Stealth" means when an application is launched, used and terminated properly, it does not leave behind any entries in the registry or filesystem.
My app runs under .Net Framework 4.6.1 and leaves behind a log file under the folder:
%AppData%\Local\Microsoft\CLR_v4.0_32\UsageLogs\ [App Name].exe.log
Who is creating this log file?
Is there any way to avoid the creation (without breaking the app)?
What's the purpose of this log?
With Windows 8 (.NET 4.5), a new NGen mode: "Auto NGen" has been
introduced. Basically, the .NET runtime generates usage logs for
managed applications. Source
Every time the application run it creates a new type of logs called
“Assembly Usage Logs” in the AppData windows directory.
Source
On my research I found out mostly that it only does this job on Windows 8+.
But in this source it says also on Windows Server 2012, but I have tried it on a Windows Server 2012 R2 and could NOT reproduce it!
I did not find a way to disable this, one solution could be to target a lower .net Framework within our application.
For an app for Windows 10 IoT Core on Raspberry Pi2, I need to use a launcher app or StartUp-Task, which creates a shadow copy of my app and launches it. I need to use this approach to be able to substitute DLLs during runtime, without having a lock on the DLLs and without disrupting running services. That's needed as the device running it, would be remote somewhere out of reach, deployed at a client's site and I need my app to be running to service the device. After updating my DLLs, I would restart it and it would run with the new libraries, start the launcher as default app, which then starts my app.
Before Windows 10 and UWP the approach was to use System.AppDomain from mscorlib.dll in the .NET Framework to create a new AppDomain in a cached directory. The config, executables and DLLs would be copied to a cache directory and run from there. That leaves the original DLL available for substitution and doesn't put a lock on them. This was also a very useful technique used in IIS and webapps, which needed to run without interruptions even if the code needs updating. The open threats keep servicing open requests until these are done and new requests will be serviced using the new updated versions.
Now in Windows 10 System.AppDomain is not available anymore. I tried Windows.System.ProcessLauncher but encountered several issues with it. First I have to register the EXE in the registry to allow launching it. Then it tells me I can only run it from an app container. I didn't get it to work as of now. It's just a tedious and messy approach IMHO.
Now to my question: What would you use as an alternative to the described old approach on Windows 10 IoT Core? Does anyone have a small snippet of sample code to share? Or perhaps a link pointing in the right direction? Any advice would be appreciated.
This approach is not compatible with the Universal Windows Platform app model.
You will have to push an updated package of your app.
I developed a c# software using windows 7. IDE is Visual studio 2010 professional, and the only dll it use is speech.dll. I generated an installer using the default way build menu->publish _software name_ -> Finish, when the setup wizard is on.
I provided the whole publish folder into 2 computers, windows 7 and windows 8. App installs fine in both machines but when it is about to run, windows 8 is saying Windows SmartScreen prevented an unauthorized app from running
Why is this happening? Please help!
Windows 8's SmartScreen is designed to "protect" consumers from malicious programs. In order to be trusted, you need to either buy a cert or sign up to distribute your application through the Windows Store (which costs less money).
It's a terrible move by Microsoft and will hurt devs like you, but there's currently no way around it. You will need to press "More information" when the SmartScreen alert comes up and then press the "Run" button to let your application run.
I've written many versions of windows services and installed them on a 64-Bit system with 32 GB running Server 2008 R2 Enterprise.
I create the services using this recipe:
http://msdn.microsoft.com/en-us/zt39148a.aspx
"Walkthrough: Creating a Windows Service Application in the Component Designer"
I create the .msi and corresponding setup.exe on my Win 7 laptop (c#, vs2010 SP1, .NET 4).
NORMAL BEHAVIOUR
after testing a Windows service on my laptop, I copy the .msi and setup.exe to a folder on the win2008 R2 Enterprise server (using copy and paste via remote desktop); I use the server's Control Panel to uninstall, right click the .msi and choose Install, then walk through the Setup Wizard. No problem. Works most of the time.
ABNORMAL BEHAVIOUR
The install runs for perhaps 15 minutes or longer; it never finishes; eventually a dialog states
"(?) Installer is no longer responding."
with options to [Retry] or [Cancel].
At this point, the progress bar is a short as it could possibly be and at the far left, beneath the "P" of "Please wait...".
Clicking Retry does not help. It's been over 30 minutes and counting since I clicked Retry and the progress bar has not advanced even a pixel.
MORE INFORMATION
(a) the service installs without any problem on another server, a Win 2008 R2 web edition.
(b) as mentioned above, the Windows service both installs and works properly on my Win 7 development and testing environment.
HISTORY / SPECULATION
a couple of weeks ago, I was unable to install a service from the win 2008 R2 Enterprise server. I could not find it in Control Panel/Uninstall even though the .msi claimed it to be installed and the service also continued to appear in the services.msc console. Even disabling the service did not help. For that reason, I cloned the code, changed the service name slightly, and successfully installed that service which has been running for while without issues.
Today, a similar event happened, the only difference being that I can see that service in Control Panel Uninstall. Because it would not uninstall, I tried my same cloning trick but this time it failed.
Next step: using the above walkthrough, I created a do nothing Windows service and made it useful by importing my client classes into it from the original c# project file.
The re-built from the ground up Windows service works as designed on my laptop but refuses to install on the R2 Enterprise server.
Any ideas?
Please and thank you.
P.S.: i posted this at so because imho it's more likely something that a developer is likely to encounter prior to handing off her/his code to a sysadmin.
BTW, I could not find anything related at so; ditto via Google.
in this particular case, it is some very weird server rights condition
MORE INFORMATION
although my server account is not Administrator, I'm a member of both local and domain Administrators for this 2008 R2 box.
I had tried many ideas, including creating the example in the walkthrough and trying it. No luck.
The boxe's Administrator was able to install my service using installutil.exe so I tried installutil.exe but it would only work for me using the Administrator's credentials.
For that reason, I suspected it might be a rights issue, so I tried with my credentials installing the walkthrough example on the H:\ drive. Success. Next, I tried installing the troublesome Windows service on C: in a different location. Again, success.
What is strangest about this issue is that many times I had no problem then suddenly a problem arose to block my development efforts.
A sign that a Windows service will install is when a dialog asking permission to continue appears almost immediately after starting the install. Another clue that success is possible is being able to successfully uninstall any previous version via Control Panel.
I appreciate everyone's efforts to help me with this. Thank you.
I've had similar experiences with my own MSI's (not just for services), as well as third party MSI's on Win2k3 and Win2k8. I never (ever) got to the bottom of it without a 'fresh' re-install of the operating system.
Just like you, I too speculate that there's something lost in (a combination or all of) the internals of the OS (registry, file-system, system restore).
I know this is not what you want to hear but (if at all possible) a clean install of the OS might do the trick for you.