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.
Related
I have a c++ program compiled with MinGW which links to libmicrohttpd to run a webserver. It normally functions correctly, but I am trying to do some robustness testing and for my current test I have tried to disable the network interface. This results in the program crashing with the dialog box: "MyProgram.exe has stopped working - A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available."
Rather than debug the program and potentially its dependencies, for my purposes, it would be fine if it would just crash silently without making the dialog box (I have another component that is meant to restart it). Is this possible to do via some sort of manifest or Windows API call?
It turns out there is a Windows API function called SetErrorMode. Passing the parameter SEM_NOGPFAULTERRORBOX will prevent the error dialog from being displayed on a crash.
There is also the RegisterApplicationRestart function which can be used to have Windows restart an application in the event of a crash (or other configurable reasons).
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.
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 ;)
We are facing the following issue:
The architecture is as follows:
A c++ native client application is connected to a native c++ server application via pipe RPC based on a IDL file.
I'm not particular savvy in this domain and havent coded the relevant parts but it works since a long time.
Since some days, one of our client-server tests fails.
Examining the issue shows that there is an exception in the very low-level RPC communication part:
Exception thrown at 0x00007FFF2649A388 (KernelBase.dll) in application.exe: 0x000006F7: The stub received bad data. occurred
The stack contains calls to functions in rpcrt4.dll.
Now the thing is we don't have any recent modifications in these parts of the code.
Neither in the functions on the client involved in that particular server RPC call.
Also, the same error occurs on my dev machine also with an older version of the code (for which the tests passed fine when this older version was tested on the test machines).
So i suspect some external issue, like updates to the windows libraries or such.
Did anyone encounter this error out of a sudden?
How should i go forward to debug and pinpoint the issue?
What i have done so far:
Debugged the client and server, and i see the call coming in on the server and the function executes fine.
It is when the result is being sent back to the client when the exception is fired on the client.
This is on Windows 10 x64, developed with Visual C++ 2017.
I've started getting the following exception while debugging a 32bit MFC C++ app under VS2010 SP1, Windows 7 64. While I can easily ignore it, I'm just wondering what it is.
First-chance exception at 0x751eb9bc in SCCW.exe: 0x80010108: The
object invoked has disconnected from its clients.
A similar question and a google search suggest its automation related, and while my app supports automation, it isn't doing anything automation related at the time. The stack frame for the active thread does not show anything much, all system DLLS (ntdll.dll,rpcrt4.dll,ole32.dll). I've been debugging the same app on the same system for a long time and only started seeing this recent, so just wondering why. Any ideas, and can it be safely ignored?
This will be some other executable that gets loaded in. It could be something that has windows hooks etc such as a virus scanner, or it could be a shell extension. Look up what SCCW is. If it is something you don't need on your system, uninstall it.
It should be safe to ignore, and you can prevent the application from stopping in the debugger by adding the exception type and telling VS not to stop on it.
Debug | Exceptions...
Then under Win32 Exceptions untick "80010108 Server Disconnected from clients".