Put on your wayback hats...
I have to use DDE (sorry, absolutely no choice in this) to communicate with an industrial control system. The control system is the DDE server and runs on the same Windows 7 PC as my DDE client. The client uses MfcDDE as it's interface which in turn makes calls to the DdeClientTransaction() functions.
The DDE advise operations work as expected after calling MfcDDE to establish them with DdeClientTransaction(XTYP_ADVSTART). All data points of interest are successfully read through the advice mechanism.
Unfortunately, attempts to write data through the DdeClientTransaction(XTYP_POKE) function fails. Within my client, DdeGetLastError() returns DMLERR_INVALIDPARAMETER (16390 0x4006). Interestingly, DDESpy (yes, I am that desparate) is reporting DMLERR_POSTMSG_FAILED (16396 0x400C).
The client worked in its initial NT implementation, but rebuilt and running under Win7, the XTYPE_POKE is failing. I've contemplated both security and threading as possibilities.
I've been unsuccessful finding a pointing gun for DDE security changes between NT and Win7.
If it matters, the DdeClientTransaction() call is being made in a thread started with WinMain() calling through to AfxWinMain() and CDialog::DoModal() to get to client's functional code.
Thanks for any help you can provide...
Confirmed that DdeClientTransaction(XTYP_POKE) can only be called on the same thread upon which DdeInitialize() was called. The restriction may actually be the same thread upon which DdeConnect() was called, but my money is on the DdeInitialize() since the returned DDEIdInst is passed to DdeConnect(). I could be wrong.
Thanks for letting me work through this with you guys... :)
Related
We have a legacy VB6 app which has started, from time to time, hangs. We thought it may be to do with a shift to Citrix, but can now replicate the behaviour on a thick client on Win10. We don't think that we have seen this before on earlier Windows versions, but are still checking logs to confirm that.
We experience the behaviour when tabbing into a text box and then tabbing out. As we pass through it, we are making a simple ado call to lookup/validate some data in a text box. As part of the correct program running we are logging
“Opening Dataset: SELECT ... FROM ... ”
“Opened Dataset”
Between these 2 log statements is simple ado data retrieval code with which we have had no problems previously. It is in an ActiveX dll and is running synchronously. Most importantly is that between these 2 log statements there is no DoEvents or api call which would yield control. As far as we can see, it should be a purely synchronous operation.
When the system crashes, which happens sporadically, we can see other logging statements appear between these 2 which can be either resource status (e.g. how much memory, gdi/user objects - which would usually be found because a timer has triggered in the main form) or focus type events - which aren’t timer driven - at least in our codebase.
“Opening Dataset: SELECT ... FROM ... ”
“Resource Status: ...”
“Opened Dataset”```
or
“Opening Dataset: SELECT ... FROM ... ”
“TextItem.OnLostFocus Item1 ...”
“TextItem.Validate ...”
“TextItem.OnGotFocus Item2 ...
“Opened Dataset”
So my initial question is, in what scenario can what should be a synchronous operation be interrupted and appear to act asynchronously.
For example, and we aren’t doing this, I could imagine writing some unsafe code whereby by using a multimedia timer (on another thread) and supplying an AddressOf parameter to the address of a function on one of our modules, that that timer initiates execution of our code, separate to the correct control flow. Other than something like that, I just can’t see how synchronous vb6 code could be interrupted in this way.
I’d be really grateful of any thoughts, suggestions or advice. I’m really sorry if this is soo vague. It perhaps reflects how I’m struggling to get my head round this problem.
Just to say, we tracked this down to Windows 10 plus an old (out of support) socket component we are using. It looks like it is pumping the message queue "at the wrong time" and hence we are seeing UI events appear in the middle of a synchronous process. We don't see this behaviour on earlier Windows versions.
I don't know what may have changed in Win10 which would result in this, but we obviously need to upgrade.
In our case we had a few long running timers to pull status/changes from the DB which caused this. We are using ADO with SQL Native Client and MARS, which worked great up until Windows 10 where intermittent lock ups occurred. Logging and Windbg confirmed this was happening when 2 requests where hitting the ADO connection at the same time. The error from ADO was "Unable to open a logical session" error number -2147467259, and actually caused SQL Server 2014 (running on another machine) to block all other client queries from multiple different applications and machines until the locked up app was killed. I could not replicate this in the IDE as apparently that forces timers to work the way they always did. The fix was to async our ADO implementation and put a connection manager on top of the SQL connections to force requestors to wait their turn (basically taking the Win10 async'd timer feature back out). My only performance impact was the additional few milliseconds of delaying the timer fired SQL query when it collided with a another query.
Our application has a feature to actively connect to the customers' internal factory network and send a message when inspection events occur. The customer enters the IP address and port number of their machine and application into our software.
I'm using a TClientSocket in blocking mode and have provided callback functions for the OnConnect and OnError events. Assuming the abovementioned feature has been activated, when the application starts I call the following code in a separate thread:
// Attempt active connection
try
m_socketClient.Active := True;
except
end;
// Later...
// If `OnConnect` and socket is connected...send some data!
// If `OnError`...call `m_socketClient.Active := True;` again
When IP + port are valid, the feature works well. But if not, after several thousand errors (and many hours or even days) eventually Windows socket error 10055 (WSAENOBUFS) occurs and the application crashes.
Various articles such as this one from ServerFramework and this one from Microsoft talk about exhausting the Windows non-paged pool and mention (1) actively managing the number outstanding asynchronous send operations and (2) releasing the data buffers that were used for the I/O operations.
My question is how to achieve this and is three-fold:
A) Am I doing something wrong that memory is being leaked? For example, is there some missing cleanup code in the OnError handler?
B) How do you monitor I/O buffers to see if they are being exhausted? I've used Process Explorer to confirm my application is the cause of the leak, but ideally I'd need some programmatic way of measuring this.
C) Apart from restarting the application, is there a way to ask Windows to clear out or release I/O operation data buffers?
Code samples in Delphi, C/C++, C# fine.
A) The cause of the resource leak was a programming error. When the OnError event occurs, Socket.Close() should be called to release low-level resources associated with the socket.
B) The memory leak does not show up in the standard Working Set memory use of the process. Open handles belonging to your process need to be monitored which is possible with GetProcessHandleCount. See this answer in Delphi which was tested and works well. This answer in C++ was not tested but the answer is accepted so should work. Of course, you should be able to use GetProcessHandleCount directly in C++.
C) After much research, I must conclude that just like a normal memory leak, you cannot just ask Windows to "clean up" after you! The handle resource has been leaked by your application and you must find and fix the cause (see A and B above).
Can I get an event callback to my kernel driver when the boot process has completed, or when a user logs in?
The simple answer is no.
The long answer is yes, but why?
I'll answer the second part, because it's easier. You can easily register to recieve a notification when any process is launched. A short examination of Windows Internals will tell you that from Vista and up, the process userinit.exe is the first process to be executed in any given user session.
To the first part, this very much changes depending on your definition of boot process. Is it when a GUI is loaded? Is it when the computer can receive network requests? Does it matter which network requests (TCP/IP, SMB, RPC)?
The answer to each of these is very different.
When win32K has finished loading
When the TCP/IP stack drivers finish loading
When specific services (RPC, Server service) are done loading
What is the problem you're trying to solve?
I have developed a driver for Windows XP which is able to monitor the execution of processes.
A callback function receives the notifications using standard WDK API (PsSetCreateProcessNotifyRoutine).
The driver then decides if the process should be authorized or not; if not, it must block its execution/kill it.
What is the cleanest way to intercept execution that way? I do not mind if it is not documented, but I would rather not resort to hooking, if possible.
Ok, according to this document:
http://download.microsoft.com/download/4/4/b/44bb7147-f058-4002-9ab2-ed22870e3fe9/Kernal%20Data%20and%20Filtering%20Support%20for%20Windows%20Server%202008.doc
I need to install a minifilter for IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION and check for PageProtection == PAGE_EXECUTE.
PsSetCreateProcessNotifyRoutineEx (Vista+) will allow you to cause the process-creation operation to fail by changing the CreateInfo->CreationStatus member to an NTSTATUS error code.
We have a fairly standard client/server application built using MS RPC. Both client and server are implemented in C++. The client establishes a session to the server, then makes repeated calls to it over a period of time before finally closing the session.
Periodically, however, especially under heavy load conditions, we are seeing an RPC exception show up with code 1754: RPC_S_NOTHING_TO_EXPORT.
It appears that this happens in the middle of a session. The user is logged on for a while, making successful calls, then one of the calls inexplicably returns this error. As far as we can tell, the server receives no indication that anything went wrong - and it definitely doesn't see the call the client made.
The error code appears to have permanent implications, as well. Having the client retry the connection doesn't work, either. However, if the user has multiple user sessions active simultaneously between the same client and server, the other connections are unaffected.
In essence, I have two questions:
Does anyone know what RPC_S_NOTHING_TO_EXPORT means? The MSDN documentation simply says: "No interfaces have been exported." ... Huh? The session was working fine for numerous instances of the same call up until this point...
Does anyone have any ideas as to how to identify the real problem? Note: Capturing network traffic is something we would rather avoid, if possible, as the problem is sporadic enough that we would likely go through multiple gigabytes of traffic before running into an occurrence.
Capturing network traffic would be one of the best ways to tackle this issue. If you can't do that, could you dump the client process and debug with WinDBG or Visual Studio? Perhaps compare a dump when operating normally versus in the error state?