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.
Related
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 ;)
To implement the copy and paste functionnality in a MFC application, we invoke the AfxOleInit() method.
We also use RAPI to communicate with Windows Mobile devices.
When AfxOleInit is not used, we have no problems.
But as soon as AfxOleInit is actually executed, we reproduce the following sequence:
The mobile device is in its cradle and correctly connected via Windows Mobile Device Center (WMDC) to the PC,
CeRapiInitEx and then CeRapiUninit complete successfully
We remove the mobile from the cradle which deconnects from WMDC
We reput the mobile in the cradle and, a second time, CeRapiInitEx and then CeRapiUninit complete successfully
We remove the mobile from the cradle which deconnects from WMDC
At that moment, a message appears in the "Output" tab of Visual Studio: "the RPC server is unavailable"
We reput the mobile in the cradle and this time CeRapiInitEx fails with the return value "the RPC server is unavailable"
We have tried to put the code which contains the calls to the RAPI dll functions:
directly in a MFC application,
in a DLL,
in an ActiveX
we reproduce the error in all cases.
Note that, if this code is put in another process launched via a CreateProcess from the MFC application, there are no errors.
You can download the application which reproduces this error at the following address:http://iode-informatique.com/tests/winmob_mfc/rapi_test_app.zip
Note that if you comment the call to AfxOleInit, the error doesn't occur.
Best regards.
I need suggestion about YAMI library . I have a system which receives Json string from external interface and parse that received string and send that message to internal ip address for the required action.
The exchange of messages within the internal ip address has been taken care by Yami library. everything works fine but occasionally it displays yam i/o error and system doesn't response unless it is restarted.
The whole software is written in C++ and C and development os is fedora 11.
I have tried to investigate the problem but I am bit clueless as I have not found much help on internet and my testing method doesn't work.
its strange that system works for few hours and then crash . For example If I leave system idle for half an hour and then try to send message via external interface it crashes producing yami i/o error or even while sending continuos command it crashes.
Any help or suggestion will be of great help.
Thanks and regards,
Sam
It looks like this exception is from a core::io_error result which is translated to a runtime exception by details::translate_result_to_exception(). Most of this error originates from the source code in yami/posix in your case.
What you have to do now is figure out where the error originates and ultimately the source of the issue. You should be able to get a rough idea from what happens in your code when the error occurs (are you creating a new connection, sending data, receiving data, etc...).
If that doesn't yield any obvious results I would probably create a test project using the yami source code instead of the library file so I would be able to trace into the yami code to where the error originates from.
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.