I have an EXE COM server (used to elevate our application to a higher integrity level) which is downloaded to %temp% and registered by an ActiveX control. This COM server works pretty well on Vista machines. On Window 7 machines I got something wired: the COM server can be downloaded and registered successfully, but I got the error 0x80080005 (Server execution failed ) when trying to initialize the server by CoCreateInstance. If I copy the COM server to %temp% manually instead of downloading it via internet then everything works as expected. I am suspecting that the downloaded EXE files have some special attributes that prevent it been loaded but have no idea how to figure it out.
Does anyone have the same experience or have any clue for this issue? Any suggests will be highly appreciated.
Joe
Yes they do. Start a command prompt and use DIR /R. You'll see the alternate data stream in the file. The one that says: "don't trust this file, it came from an untrusted source".
You can delete them with the filename:streamname syntax. Check if that's okay with your customer first. I don't know many that are thrilled about EXEs getting downloaded and bypassing normal security rulez.
Related
I have a problem with a web service that is installed and started with a .msi that is created with the WiX toolset.
The service can be installed and started on all the machines I tested so far (shown as running in the Services Manager) but on some machines it is not reachable (for example via a browser) and not shown in the list of listening ports on that machine (displayed with 'netstat -a').
I am trying to figure out what's going wrong but I am not really familiar with web service development and configuration. It's a third party service, thus I don't know how it works internally.
A good starting point for me would be to find out, what exactly happens when a service is installed and started during the execution of the .msi-file.
Maybe I could try to tackle the problem on a lower level then.
Below is my code in the ServiceInstall-Element:
<ServiceInstall
Id="ServiceID"
Type="ownProcess"
Vital="yes"
Name="ServiceName"
DisplayName="ServiceDisplayName"
Description="Lorem Ipsum"
Start="auto"
Account="LocalSystem"
ErrorControl="normal"
Interactive="no"
Arguments="action=run">
</ServiceInstall>
The argument is important - without it, the service won't start or run.
Maybe someone else encounterd the same or a similar problem and can help me out.
Thanks already in advance - each hint is appreciated.
EDIT I (15.04.18):
As it might be a problem with the specific service, I will add some further information here:
It's a third party software called CryptoLicensing:
http://www.ssware.com/cryptolicensing/cryptolicensing_net.htm
Part of this software is that specific program, that serves as a License Server and does the license registration, for example in a customer's network.
The service can be run as a Windows application or installed and run as a Windows service. In both cases it should be listening on a (pre-)specified port on the installed machine.
Whenever I start the .exe as an application, everything works as intended. The service is reachable (for example with the browser) and can be accessed from other machines in the network.
When the .exe is installed and started as a service, it does not work as intended on every machine. For example if I install and start the service on my laptop, it is shown as running in the Services Manager, but is not reachable on its assigned URL (not even on the localhost) nor is the specific port displayed in the active listening ports, for example with 'netstat -a'.
The service itself starts without any error messages and does not log any errors or exceptions as it seems to be running without any problems.
I contacted the vendor, but sometimes he doesn't reply quickly and he is not very specific in his replies.
Before asking the question I assumed that it was a problem with the Windows user rights and the WiX installer but during the discussion here I had the feeling that it might a problem with the service itself.
I hope this 'new' piece of information helps in isolating and location the problem.
Thanks to everyone who helped so far!
Hopefully not stating the obvious here, but WiX doesn't do much except populate the ServiceInstall table in the MSI file, so this is about why Windows Installer won't start the service. ServiceInstall table:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa371637(v=vs.85).aspx
Also, this isn't really about ServiceInstall - it's probably about the ServiceControl element in your WiX source, but it's not clear whether that's how you're starting it or if you're starting it manually later on. That does make a difference. What is the error message and where are you getting it, and is it a 1920 or 1921 error (in the context of ServiceControl).
The main reason a service will start on one system but not another is missing dependencies. If your service is C++ based (the post doesn't say) then there are probably dependencies on C runtimes, UCRT runtimes, MFC or ATL runtimes and so on.
First: are you sure this service is intended to run as LocalSystem? (MSDN, SO).
Second: did you check the event logs in detail for anything obvious? If the service is good you should find a hint at least. Something to start with. I find that I sometimes miss the actual logs in the event viewer because it is so "crowded". My take on it: empty the log and stop and restart the service.
Something locking / blocking: If the service installs and runs OK I would suspect other factors such as firewalls (hardware & software), security software in general (anti-virus, malware scanners), network configuration issues (proxies, WINS, DNS and all the complexities involved in networking). Is the service trying to reach an UNC path?
Diverse Machines: What are the target machines? Are they virtual, are they physical, are they test machines, are they operative SOE machines in corporate networks? Are they the same OS version and edition?
Further Ideas: It is not quite related, but maybe skim this list of suggestions for debugging from another answer (I am not sure why it was down-voted, I think it is an OK list to inspire debugging ideas): Windows Application Startup Error Exception code: 0xe0434352 (maybe just skim the bolded words for ideas - Recommended).
sc.exe: And finally, perhaps check the sc.exe tool (Service Control) and see if it can provide you with some useful information for debugging.
sc.exe in the context of killing hung services (sample use).
sc.exe from MSDN
Some further links:
Windows Services Frequently Asked Questions (FAQ). Content seems to be up to date - at face value at least. These guys claim to be experts on services. I have no idea who they are.
Essential Tools for Windows Services: SC.EXE
Run Service Control (sc.exe) command on secure port
After almost 20 months we finally (and accidentally) found a solution to the problem! For the few machines, on which the service did not run properly, setting the NoInteractiveServices value in the registry to 0 did the trick. A value of 1 (which is default) means that no service is allowed to run interactively, regardless of whether it has the SERVICE_INTERACTIVE_PROCESS property. More information on Interactive Services.
I am not completely satisfied with the solution, because on all the other machines NoInteractiveServices is set to 1 AND the service runs properly anyway. However, on the machines where the service did not run interactively this solution worked for us. Thus I will accept this as an answer.
If anyone has more information on this issue and can explain why this works, feel free to
add them - I would be very interested!
Ok guys, I've been trying to get this working for a few weeks in my spare time, and all day today, and I have nothing to show for it, so here's my question.
First off, the end goal for this is to read and write basic information (id #s, names, etc.) from a remote mysql database, to a C++ program written in Visual Studio 2010 Pro, or something equivalent (and free). I access the server from my laptop with SSH, and I can call family members to mess with router settings and such.
I'm trying to use a MySQL database on a Ubuntu Server machine that I access remotely from a Windows 7 laptop. I have installed MySQL Connector C++ from the MySQL website (the msi installer). NOTE: I have not done anything with the Connector install except run the exe I downloaded. Didn't think I needed to compile anything, but I'm wrong a lot. I have created a database, a user who has privileges to the database, and this user can (in theory) connect from any ip, because it is declared as 'username#'%'. I also changed the my.cnf file so that the bind-address line is commented out. I used 'mysqladmin ping -h serveraddress -u username -p' and that gave me 'mysqld is alive', so I'm assuming the database is accessible from any ip remotely. So, I opened up VS 2010 Pro, made a new project, went to tools, and then 'Connect To Database'. I selected Microsoft MySQL Server and put in the information exactly as I did for mysqladmin. I clicked Test Connection and I get an error box that ends with 'provider: Named Pipes Provider, error 40 - Could not open a connection to SQL Server'. Sorry for the block of text, just want to give all the details I can.
Hopefully I'm close to making this work, I'm not pressed for time but I'm really tired of not being able to work on anything else in the project, since it all branches from this database connection.
Thanks you all! I'll reply with whatever you need me to during the day, I'm not much of a night owl anymore =)
UPDATE:
I have the sample code from the mysql site compiling correctly, it was just a matter of finally getting a few hours to sit down and fix linker/library errors one at a time, downloaded the boost libraries, and changed include directories to direct paths when I could get them to work correctly. Now all I need to do is learn how to use it lol
Thanks all!
Not sure if this is the problem but be sure to use the 32 bit ODBC Administrator if you are building a 32 bit application. If you are on a 64 bit PC, by default you are going to be using the 64 bit ODBC Administrator and consequently your 32 bit application won't actually see the DSN that you've created. Run the 32 bit ODBC Administrator using this path: C:\Windows\SysWOW64\odbcad32.exe and then create your DSN.
We have a Plugin that runs on Browser. This Plug is a DLL that creates an out proc COM Server (say MyApp.exe). Note that this app runs as an elevated server as given here.
The Entry point for MyApp.exe registers the CLSID in to ROT. Hence when the Registration occurs to ROT I am not sure if it maintains any security context for the running process.
From the plugin dll we try to fetch the registered instance of MyApp.exe. This fails saying Operation is unavailable since the plugin is running through an browser as Medium IL Level. (Yes, it works for me if UAC is turned OFF, issue is only when it is turned ON).
I've tried the registry modifications as mentioned in the above link and it does not work for me.
Please suggest.
Thanks
I am facing a rather strange and very specific DCOM related problem and I am hoping someone might have encountered it and solved it.
I am trying to instantiate a COM object in an EXE server on a Windows 7 machine (call it W7). The client resides on a Windows XP machine (call it WXP). On WXP the logged-in user is a domain user. On W7 the user is a local user. I have (afaik) correctly set all the DCOM rights, authentication and account privileges. There is no firewall involved.
All I get is that the COM EXE server process is started on W7, with the username I expect, but does not seem to even reach its WinMain function and remains hanging and never dies unless I kill it. I can attach a remote debugger (Visual Studio 2010) to it which will warn me that the process might be deadlocked, and when I break it, it stops in a message queue loop (GetMessage/Dispatch).
The client gets a (seemingly valid) pointer but any attempt to use it, results in E_ACCESSDENIED.
If anything from the scenario above is changed, the instantiation of the COM object succeeds and the object behaves correctly.
I know the chance is slight to find an answer but any tip is extremely welcome.
Thanks.
DCOM client and server either needs to be both the same local administrator on workgroup, or domain users on the same domain.
You can use this test app to check if your two machines are configured correctly:
http://support.microsoft.com/kb/259011
This way you make sure that your machine's permission and firewall are setup properly first without your own code.
Answering my own question...
It turns out that in the client CoInitializeSecurity didn't have all credentials it needed after all... It was called too early, before the credentials were known.
I discovered this after using CoSetProxyBlanket (as described here: How does impersonation in DCOM work?) on each component I was instantiating. Every component on which I called CoSetProxyBlanket was correctly working. This triggered me to go and double check the CoInitializeSecurity.
It remains strange that the reverse connection (from W7 to WXP) worked, but this is another research I need to do. The current question can be closed.
I have a service application that on startup and shutdown logs an event log record.
I rebuild the application frequently and also then the executable on the host machine. And here is the problem, after my service shutdown the Windows Eventlog service (not the event log viewer) is holding an open handle to the executable so I cant update it.
I have the event log messages embedded in the executable, i could move it out but then I just move the update problem to another file.
I've double checked and I have paired ::RegisterEventSource/::DeregisterEventSource correctly.
Anyone encountered this problem ?
I've also run into this issue, so just adding some of my experiences.
I have a Windows 2008 Service system (have not seen this on 2003 Server), and when I stop my service, and instance of svchost.exe loads the service executable (visible using vmmap.exe or Process Hacker) preventing it from being deleted/overwritten during uninstall/install. The instance of svchost.exe is running the DHCP Client (Dhcp), TCP/IP NetBIOS Helper (lmhosts), and Windows Event Log (EventLog) services.
In our case, we have created a registry entry to make our service executable an event source. (though I'm unsure exactly why we are doing this, or whether we should be doing this).
Empirically, if I remove that registry entry before stopping the service, the executable is not loaded by svchost.exe and all is fine. If the service has already been stopped and executable loaded by svchost.exe, restarting the Event Log service (or killing the process) also frees up the executable.
I'm guessing our service is not well-behaved (perhaps a side effect of being a 32-bit process on 64-bit OS?) or correctly installed, but haven't isolated the issue yet.
Update: It appears this issue is only happening on HP systems (and not Dell or IBM) which is curious. There are HP-specific management components installed, so perhaps one of them is altering the behavior somehow?
I've also run into this issue. In my case, nxlog service reading logs. Simply stop nxlog service before replace event source file.
I think it is probably the event log viewer. Close the viewer and you'll be fine.