We're currently facing some issues trying to start a Service in Windows, which is an executable file and the output of a compiling process using .NET framework for C++ (Windows\Microsoft.NET\Framework\v2.0.50727).
We are able to compile, start and execute the exact same service in our DEV Environment, which consists of Windows 7 installed in Virtual Box with VisualStudio2005 (it's old software, I know...).
When we do it in our Test environment, we get a timeout error when trying to start the Service (1053: The Service Did Not Respond to the Start or Control Request in a Timely Fashion.). The server is running WindowsServer 2008 R2 Standard. We already tried to change the timeout time, without success. We also compiled the source code using the same Visual Studio 2005 SW and although we were able to compile it successfully we are still getting the same timeout message.
We are currently trying to understand what's objectively causing the different behaviour. The most obvious difference is the windows version, naturally, but since the compilation output appears identical and there are no errors during the compilation process in both environments and both output logs are identical as well we are running low on ideas to identify and validate objective differences. Our latest approach consists in trying to understand if by using Dependency Walker (dependencywalker.com) we are able to identify any issue regarding DLLs (we also checked if there is any corrupt DLL or system file in the environment and there isn't any, using the windows command for it). We're also checking some of the suggestion made on the following post: Error 1053 the service did not respond to the start or control request in a timely fashion.
Any one faced a similar issues? If so, can you suggest any kind of approach to identify the reason why the service isn't staring, other than the ones here mentioned?
Thanks in advance.
We ended up extending the timeout time regarding Service startup in Windows to 10 minutes followed by the necessary restart and we managed to start the service normally and almost immediately, which makes us think that the timeout time was never really an issue here. Although we haven't been able to pinpoint the exact cause we are still inclined to think that it was a Windows/Server related issue.
Related
We have a bigger software running on Win CE6 without problems. The core functionality is implemented in a COM server DLL that provides connection points. The COM client program registers event handlers for the connection points on program startup to get status notifications etc. On program exit it unregisters the handlers by calling the corresponding IConnectionPointImpl::Unadvise methods.
Now, we are porting the program to run on Win EC 7. The new Board Support Package (BSP) for Win EC 7 works well. There are also different versions with different options, created at different times with different sources from Microsoft, but our software always show the same issue.
On program startup, ~10s after launch, IConnectionPointImpl::Unadvise is called unexpectedly on all registered event handlers. We only have one method in our source code that calls IConnectionPointImpl::Unadvise and this is definitely not executed.
The issue appears ~95%, but sometimes the program starts and runs without problems. We cannot use the Debugger because of the size of the program, the performance is very poor.
We guess, that the COM runtime calls the IConnectionPointImpl::Unadvise methods for some reasons. But we have no idea, how to prevent this.
Has anybody observed the same issue? Is there a solution/workaround available? Thanks.
So we finally found how solve this problem.
We remove our dependency on MarshalByReObject and replace it by a proper implementation of ISerializable.
That allow us to load properly inside custom AppDomain our assembly and events are not loose anymore.
But this has a side effect on path where assembly a configuration file are loaded. To solve this we also implement an AppDomain.AssemblyResolve event which allow us to redirect the loading in a proper place.
I hope this can help you ;)
I'm trying to call any WCF service in code locally which gives me the following exception:
WinHttpException: The group or resource is not in the correct state to perform the requested operation.
Some code example: await service.ReadMultipleAsync(filters.ToArray(), null, 1);. This might not say anything though. The weird thing is that it worked before updating windows 10. This might be a coincidence, but I have absolutely no code changes.
I can also talk directly to the WFC service through some tooling, so it cannot be some sort of IP blocking or firewall. But doing this through code results in the error, both using Kerstel or IIS Express.
Possible relevant packages:
.Net core - 2.2
System.ServiceModel.... - 4.4.0
I'm currently clueless. Any help would be appreciated!
Edit:
A more detailed exception:
System.Net.Http.WinHttpException (8007139F, 5023): The group or resource is not in the correct state to perform the requested operation
at System.Threading.Tasks.RendezvousAwaitable`1.GetResult()
at System.Net.Http.WinHttpHandler.StartRequest(WinHttpRequestState state)
I did a rollback from windows 10 version 1903 to 1803 and it suddenly started working again. Not really a solution but it works. Still no clue on what's wrong. Might be a bug?
We have a 64bit application running as service on Windows 7 64bit. When we start a service manually, it works fine everytime. When the service is started automatically with system startup, sometimes (like 1 in 10) it fails. Problem is with LoadLibrary function which is in fact the first thing it does. It is a load of our DLL where the most of the code is. I can't reproduce it on my computers, so I am just sending special testing binaries to colleague abroad. I added text outputs to file using unbuffered write operation so I can see exactly where it disappears. There is no crash dump, there is no exception, there is no NULL retrived, it just exits somewhere in LoadLibrary and service is not running after system startup. Our library does not have DllMain, but if I add it, it does not get there (in fail case). I tried delay loading of dependent system libraries, no success. It seems like sometimes something is not yet started in Windows and so the initialization fails, I am not sure. But adding sleep before LoadLibrary does not solve the problem (too late to sleep?). Do you have any ideas what is going on and how to proceed? I am currently going to remove the code from our DLL step by step to remove the lib dependencies one by one to see if in some moment it will start to work. I will be happy to provide additional information when needed.
Lenovo RapidBoot Shield app was the reason.
"RapidBoot Shield works by delaying non-critical applications and services to help your system boot faster. However, in some instances, RapidBoot Shield may delay an application and/or service that is critical to the system startup. This can cause the system to boot slower than expected or some applications may be unable to start normally."
We have a unmanaged C++ TCP server application running as a Windows service that is silently crashing after few days of run on Win2003 server. There is no Dr. Watson log file getting generated (no issue with Dr. Watson log as it catches other crashes in same application). Due to lack of Dr. Watson log file, we are unable to progress on how to debug this further..
The TCP server application is sort of HTTP processor. It connects to wide range of webserver and processes data.
Can someone please guide me what can be done to debug the silent crashes.. There are 1000+ users connected to this server at any instant and thus its not possible to run the same in debug mode. The crash is not reproducible and happens once in 5-10 days on one of the 6 servers..
Any tool that can help to debug these silent crashes. The application is a pure C++ application without any MFC or STL..
Thanks in Advance.
Krishna
The last time I had a silent crash problem like this, it was because of C runtime parameter validation., which by default just calls TerminateProcess without any other goodness (depending on which version of msvcrt*.dll you link to). If this is the cause of your problem, you can avoid it by calling _set_invalid_parameter_handler and giving a handler that either calls DebugBreak (forcing a crash) or does nothing, allowing an error code to be returned to the caller. Details in the link above.
I'm working on a bug where I have an MFC application that does weird things when installed in when Sophos Safeguard hard drive encryption is installed. I'm sorry to be so vague here, but I'm writing this away from the office so this is all from my (poor) memory.
Three things I've noticed:
AfxGetResourceHandle() doesn't return a consistent resource handle. There is a single case where we try to load a string resource, and for some reason, the resource handle that we get from this method is different to all the other stings.
Can't construct a CDocumentTemplate. There is a trace error which I cant seem to recall. Will edit and post when I'm in tomorrow.
This behaviour appears to manifest in a Visual Studio 2005 version of the project, but not a Visual Studio 2008 version. Unfortunately moving to the 2008 version is not an option.
The bug is not always reproducable if I step through with a debugger. Also, bringing up debug message boxes changes the behaviuor, which leads me to think that either there is some kind of race condition going on with the way MFC events are being handled, but I'm not sure how I'll ever know for sure, or even what I can do about it if I did.
I think there's some underlying reason that the app is behaving weirdly, but what I've posted are more symptoms. Can anyone think of what I should check for?
I've run Windows update on the test environment to ensure everything was up to date, and I've examined the process in procmon to see if the disk encryption stuff was getting in the way and conflicting with files - it didn't appear to be, but it does appear to be involved in some way as our app accesses Sophos related paths in the temp directory.
If your code is multithreaded (which I assume it is, since you mentioned the possibility of a race condition), then the likelihood is that the decryption delays are exposing concurrency flaws. You might want to try running the application off of a network share or similar slow access device to see if it manifests similar problems.
Turned out that the antivirus software was injecting itself in a way where the antivirus' software's resource handles were overridng the app's resource handles. Yuck!