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.
Related
I have a Windows service that works perfectly when run via a user account, but fails with error 1053 when run by the Local System account. Unfortunately, whatever is going wrong happens before my main() function is called, which means I can't even insert logging calls to track down where things go wrong.
How can I debug Windows service startup failures when it's happening in pre-main() code?
Any ideas why it might fail specifically when it's run by the Local System user?
NOTE: Not sure if it's relevant, but I'm compiling with GCC, and the code depends on Cygwin.
This won't be complete answer because without actually having event log it would not be possible.
Since this happens pre-main this would be related to what your user account can do and what local system cannot.
In service property panel, for Local System account you have "Allow Service To interact with desktop". Many times this can be the reason.
The other of course is, your service is loading some libraries which are off limits to it - because of network\group security (local system cannot access network so far as I know).
You will need to eliminate one piece at time to see what happens. Or other way round - make service empty remove all dependencies and play 20 questions.
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!
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
The following method is a DCOM server method. The COM client and server is running in different WinXP machines. The COM client calls RegisterClient method to register callback interface. The problem is QueryInterface method fails with error code E_ACCESSDENIED. What could be the reason for the issue?
STDMETHODIMP CGEMExtension::RegisterClient(IUnknown** ppGEMExtensionEvents, int* nClientId, int* nResult)
{
HRESULT hRes = (*ppGEMExtensionEvents)->QueryInterface(IID_IGEMExtension,(void**)&pUnknown);
return hRes;
}
When you get an E_ACCESSDENIED, it means you have a permissions problem (don't waist your time on firewalls or registrations - the former will raise errors telling you the service is not available, and the latter will tell you the class is not registered or so). COM relies on Windows permissions, so this is what you should focus on.
In your case, if I understand the case correctly, the server actually calls the client, in order to get the right interface. For that, the user running the server should have the right permissions on the client side. A few suggestions:
As daramarak suggests, have the server and the client use the same domain user, or the same local user with the same password.
On the client, set this setting to "classic".
Give the server's user, if known to the client, additional permissions using DCOMCNFG.
This might be because the correct permissions is wrong on the other computer. Simplest way to check this is to turn on logging with secpol (Local Policies, Audit policy, turn on logging of logon events and object access) then you can see if you are trying to access the other machine.
If you are just testing then I would suggest to use the setting "run as interactive user" on the com object in component services and make sure that you have the same user with the same password on both machines. Then you must be running as the common user on the client machine. Spesifically setting the user to the common user is also possible.
As a general advice to debugging DCOM connectivity: Turn off all firewalls and such to make sure that the connection is working, then turn on security measures one by one, making sure that you leave the correct ports open and that the correct users have the correct permissions.
I give you my experience even if it may not apply directly to your specific case.
On Windows 7 at 64bit I have an exe compiled with x64 and a dll compiled at 32 bit.
A COM object lives inside the dll.
The exe (launched by the "normal" user) creates the COM object (on the same computer) asking for IUnknown and the creation is successful. Then the exe asks for a different interface through QueryInterface and it fails with E_ACCESSDENIED.
If I launch the exe "as administrator" then the QueryInterface will return with S_OK.
I did not investigate further, I suspect there is some policy about the 32 bit - 64 bit interaction.
I want to have an application or service that is running that, on some schedule, can disable access to the internet for all applications except for specific ones.
I'm trying to create a filter that can be turned on or off under programmatic control. Not just IP addresses and ports, but I want to be able to block specific applications as well, much like Zone Alarm and other software firewalls let you block.
For example, iexplore.exe, skype.exe, firefox.exe, aim.exe. But still need to allow other applications to connect as needed.
It has to work on Vista as well as XP, but I kind of expect that the method will be different on each of those platforms.
Basically, the filter has to tie the network communication back to the executable that is making the request and then allow or deny it.
Update:
On Vista at least, it looks like I want to use filters in the ALE layers of the WFP.
On XP, I'm still looking for the best way to do it. Do I really need to be writing device drivers and dealing with kernel stuff? I'm just a lowly application developer. Kill me now.
Update 2:
Currently looking at the PfCreateInterface and related Pf* API's for pre-Vista systems.
You can change both Vista and XP's firewall policies dynamically using the INetFwAuthorizedApplications interface from the Windows Firewall API.
Also see this question.
You'll have to write a device driver that filters traffic based on the executable requesting the traffic.
by limiting its access to internet using firewall. go to firewall setting advanced tab (win 7)
and do that
I'm not sure, but I think you'd need to do it by getting the program to run as a user that has limited permissions, the question is, can you make a user account that stops such things?
You'll need to redirect all (or at least many) calls to the WinSock API functions of any running program to your own replacement functions. That means getting into the memory of each running program and hijacking those functions, which is an... interesting... exercise. :-)
That might be enough of a pointer to get you started, or at least to suggest some more specific questions to ask.
Could you move aside (ie rename) the system's winsock DLL and replace it with your own ?
Yours should provide the same API, but check the the process name of incoming requests... return an error code to blocked applications and forward the calls from allowed apps onto the real DLL.