I use RpcBindingFromStringBinding to connect from MS-RPC client to local Daemon server and vice versa. I use LRPC or local Named Pipes. Randomly calls to NdrClientCall2 fails from first attempt, event if server is alive, error code is -2147467259. Freeing binding and creating new one and do request does not helps. It is reproduced when Excel process add-in start Daemon process, both can be server and client. Cannot reproduce on 2 console executable.
Any ideas?
I used RPC from C#. During start I got GC of RPC server handles. Not reproduced in tests until GC calls.
Related
We recently observe rare UDP communication issues that show the following symptoms:
A socket sendto() call fails with error WSAENOBUFS (10055)
A subsequent recvfrom() call on this socket does not receive anything, even though Wireshark shows that the network interface actually received the expected datagrams. This situation persists for approximately 8 seconds, afterwards new incoming datagrams can be received again from the socket.
In Windows System Log, there appears a Kernel-General information entry at the time of the sendto() error:
The access history in hive \??\C:\ProgramData\Microsoft\Provisioning\Microsoft-Desktop-Provisioning-Sequence.dat was cleared updating 0 keys and creating 0 modified pages.
The issue happens on a customer system running Microsoft Windows 10 Pro for Workstations, Version 10.0.17763 Build 17763.
On that system we were able to reproduce the issue with a simple test program written in C++ that echoes UDP datagrams. We verified that the thread receiving from the socket was actually responsive all the time, by specifying a timeout of 1 second using SO_RCVTIMEO, printing some “still alive” output and immediately calling recvfrom() again.
On our own test system, we were unable to observe the issue under the same circumstances as the customer. However, we were able to provoke similar effects when playing around with the network adapter settings while the test was running. Enabling Microsoft LLDP Protocol Driver showed the sendto() error and sometimes also resulted in the 8 second “silence” period, but without any Windows System Log entry.
Any hints are greatly appreciated.
The issue seems to be related to Microsoft Provisioning Tool since Windows 10 1809.
Disabling it fixed the issue in our case:
Open Task Scheduler, go to Microsoft/Windows/Manangement/Provisioning and disable Logon task.
Source: Windows TenForums
Is there a way to invoke the gevent-socketio BaseNamespace.emit on the server side since it uses environ['socketio'] to get the socket from the request.environ. How I can generate new virtual socket or emualate somehow the environ['socketio'] on the server so I can use it to invoke the gevent-socketio BaseNamespace class (for emitting a message for example).
The idea behind this is that the server itself would be able to broadcast messages on a fixed period.
Thanks
I am working on a Windows (Microsoft Visual C++ 2005) application that uses several processes
running on different hosts in an intranet.
Processes communicate with each other using TCP/IP. Different processes can be on the
same host or on different hosts (i.e. the communication can be both within the same
host or between different hosts).
We have currently a bug that appears irregularly. The communication seems to work
for a while, then it stops working. Then it works again for some time.
When the communication does not work, we get an error (apparently while a process
was trying to send data). The call looks like this:
send(socket, (char *) data, (int) data_size, 0);
By inspecting the error code we get from
WSAGetLastError()
we see that it is an error 10054. Here is what I found in the Microsoft documentation
(see here):
WSAECONNRESET
10054
Connection reset by peer.
An existing connection was forcibly closed by the remote host. This normally
results if the peer application on the remote host is suddenly stopped, the
host is rebooted, the host or remote network interface is disabled, or the
remote host uses a hard close (see setsockopt for more information on the
SO_LINGER option on the remote socket). This error may also result if a
connection was broken due to keep-alive activity detecting a failure while
one or more operations are in progress. Operations that were in progress
fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.
So, as far as I understand, the connection was interrupted by the receiving process.
In some cases this error is (AFAIK) correct: one process has terminated and
is therefore not reachable. In other cases both the sender and receiver are running
and logging activity, but they cannot communicate due to the above error (the error
is reported in the logs).
My questions.
What does the SO_LINGER option mean?
What is a keep-alive activity and how can it break a connection?
How is it possible to avoid this problem or recover from it?
Regarding the last question. The first solution we tried (actually, it is rather a
workaround) was resending the message when the error occurs. Unfortunately, the
same error occurs over and over again for a while (a few minutes). So this is not
a solution.
At the moment we do not understand if we have a software problem or a configuration
issue: maybe we should check something in the windows registry?
One hypothesis was that the OS runs out of ephemeral ports (in case connections are
closed but ports are not released because of TcpTimedWaitDelay), but by analyzing
this issue we think that there should be plenty of them: the problem occurs even
if messages are not sent too frequently between processes. However, we still are not
100% sure that we can exclude this: can ephemeral ports get lost in some way (???)
Another detail that might help is that sending and receiving occurs in each process
concurrently in separate threads: are there any shared data structures in the
TCP/IP libraries that might get corrupted?
What is also very strange is that the problem occurs irregularly: communication works
OK for a few minutes, then it does not work for a few minutes, then it works again.
Thank you for any ideas and suggestions.
EDIT
Thanks for the hints confirming that the only possible explanation was a connection closed error. By further analysis of the problem, we found out that the server-side process of the connection had crashed / had been terminated and had been restarted. So there was a new server process running and listening on the correct port, but the client had not detected this and was still trying to use the old connection. We now have a mechanism to detect such situations and reset the connection on the client side.
That error means that the connection was closed by the
remote site. So you cannot do anything on your programm except to accept that the connection is broken.
I was facing this problem for some days recently and found out that Adobe Acrobat Reader update was the culprit. As soon as you completely uninstall Adobe from the system everything returns back to normal.
I spent a long time debugging a 10054/10053 error in s3 pre-signed uploads
Turns out that the s3 server will reject pre-signed s3 uploads for the first 15 minutes of it's life.
So - If you're debugging s3 check it's not a new bucket.
If you're debugging something else - this is most likely a problem on the server side not client side.
I have a test driver program that launches a separate test server process. The test server process listens on a local port, and after it's ready, the test driver runs a test that accesses the test server.
Currently the test driver repeatedly tries to connect to the local port (loop some, sleep some, try again). It's not an optimal solution, and is clearly unreliable.
Is it possible to wait for some event that says "somebody listens on a local port"? Trying to connect to early results in a "port closed" error.
I'd like to implement the solution on Windows, Linux, and Mac OS X. If you have some tips for any of these systems, it's welcome (it's probably going to be system-specific in each case).
On Windows I use a named event for this kind of thing.
The test harness can create the event and communicate the name of the event to the server that it launches; it then waits on the event to be signalled before continuing the test. The server then connects to the event, initialises itself and once it's ready to accept connections it signals the event.
Well, if you launch the server process, you can intercept the stdout of the server right?
So have the server output "server started" when the socket ready. The driver should wait until the server sends this string to stdout, then try to connect to the server port.
I am running Vista Ultimate x64 on my system. I have an application that works fine on a remote server to send messages to the MSMQ instance running on it. When I bring the application to my local system and attempt to send a message it doesn't send, but doesn't error out either. I even tried setting up a local MSMQ instance and the same happens with that one - no errors, but no messages either. The queues are transactional and the code itself is transaction-based.
Any suggestions? I tried implementing the journal option (assuming this is like logging) and it doesn't record anything.
I dug through event viewer and the only error I am seeing (actually it's a warning) is:
MSDTC encountered an error (HR=0x80000171) while attempting to establish a secure connection with system [ComputerName]
All the standard stuff has been checked like firewalls, is MSMQ running, etc and when I put the app, unaltered, on the remote server it works 100% of the time.
The problem is not with MSMQ directly. You are using transactioning queuing which requires MSDTC to be setup and configured correctly.