I have a python program calling a 3rd party .NET library. When running it as a Windows service, the program stalls calling a .NET function. The function never returns. When running the program from the shell, the program works as expected.
Any thoughts as to why this might happen? I thought maybe something related to threading? But still I can't think of why it might work from command line but not from a Windows service.
Any thoughts on how to go about it would be greatly appreciated.
Using pythonnet (for calling .NET code) and pywin32 (for the service functionality)
Since it's a 3rd party library that I'm calling, I don't know anything about what the function that stalls does. There's a good chance it creates threads, but I don't know it for a fact.
Related
So, I have been working with MAPI API's. In that Whenever I call the MAPIUninitialize api, my application crashes. on further debugging, I found that, IMAPISession::OpenMsgStore is the reason behind the crash, whenever the OpenMsgStore function is executed during the program runtime, my app crashes exactly after the MAPIUninitialize is triggered. which is similar to the discussion in this thread mentioned below, in which soln is not available.
https://peach.ease.lsoft.com/scripts/wa-PEACH.exe?A2=MAPI-L;e6f3847a.0801&S=
I have checked my program for memory leaks, and I'm sure there is none and also, if i comment that particular api, my program doesnt crash, i dont understand the reason for the crash. I have tried all possible alternatives. Can anyone help on this ?
It mostly likely means you still have live MAPI objects. It is also possible that the sequence of MAPIInitialize / MAPIUninitialize is too quick and the common Office run-time is still (asynchronously) initializing when you attempt to shut it down.
Also, not all stores are created equal - IMAP4 is probably the worst.
It is not clear where and when these methods are used. Is it a secondary thread?
Anyway, here is what MSDN states:
A client must also invoke MAPIInitialize on every thread before using any MAPI objects and MAPIUninitialize when that use is complete. These calls should be made even if the objects to be used are passed to the thread from an external source. MAPIInitialize and MAPIUninitialize can be called from anywhere except from within a Win32 DllMain function, a function that is invoked by the system when processes and threads are initialized and terminated, or upon calls to the LoadLibrary and FreeLibrary functions.
I'd suggest playing with the MFCMAPI source code - you can run it under the debugger and see whether an issue is still reproducible or not.
Thanks for your wonderful suggestions. I have fixed the issue, my application actually calls the mapi api's defined in a c++ dll from golang. Because of that, every mapi api defined as a DLL function had different thread ID, When I tied the DLL function calls to same thread using runtime.LockOSThread() / runtime.UnlockOSThread() , it started working, no more crashes.
Ref: https://golang.org/pkg/runtime/#LockOSThread
Currently I am trying to debug a Linux .NET Core application under Linux.
The trouble is, it fails somewhere right in the beginning, and I cannot get where. Logging is impossible under current circumstances.
As far as I can see on the Internet, and (severely avoiding any kind of systematizedness and consequtiveness) on MSDN specifically, the only currently available options for Linux are:
debug remotely (would not do well in my case);
Rider EAP by Jetbrains (proprietary decision);
using lldb.
So, my questions are:
Is there any way to launch the .NET Core self-contained app (via the "dotnet Some.dll" command) in such a way that it instantly breaks (i.e. as if there was a breakpoint) at the entry point?
If not, how can one launch lldb for a .NET Core console application attached (since numerous examples and issues over the Internet all show attaching to the already-running .NET Core process)?
Once again, there is the dotnet-dump utility, which works with already-running processes as well - so that, even dumps are an unavailable ooption for processes that crash almost instantly. I expected there might have been ways to make it dump like (imaginary) "dotnet-dump collect SomeInvocation.dll" along with (actully existing) "dotnet-dump collect --process-id 1234". Is there such a way?
I'm in the process of designing an application that will run on a headless Windows CE 6.0 device. The idea is to make an application that will be started at startup and run until powered off. (Basically it will look like a service, but an application is easier to debug without the complete hassle to stop/deploy/start/attach to process procedure)
My concern is what will happen during development. If I debug/deploy the application I see no way of closing it in a friendly and easy way. (Feel free to suggest if this can be done in a better/user friendly way) I will just stop the debugger and the result will be WSACleanup is not called.
Now, the question. What is the consequence of not calling WSACleanup? Will I be able to start and run the winsock application again using the debugger? Or will there be a resource leak preventing me to do so?
Thanks in advance,
Jef
I think that Harry Johnston comment is correct.
Even if your application has no UI you can find a way to close it gracefully. I suppose that you have one or more threads in loops, you can add a named manual reset event that is checked (or can be used for waits instead of Sleep()) inside the loop condition and build a small application that opens the event using the same name, sets it and quits. This would force also your service app to close.
It may not be needed for debugging, but it may be useful also if you'll need to update your software and this requires that your main service is not running.
We have an application generated using the Sculpture software package. That means the project is roughly equivalent to the code in a Prism application.
Part of their model is that all WCF Service calls are performed synchronously, but on background threads (actually they are async calls as well, but the Sculpture background thread methods wait around for the response before executing any following code).
When we deployed the application, we found that around 50% of all machines tested would not get past the first service call. We cannot see any pattern in the machines that fail as they are have a mixture of both Debug and Release Silverlight runtime and Windows 7 on machines that work as well as fail. It fails the same on different browser so is machine specific. The only clue is they all seem to be older PCs.
Ideas anyone?
Found the cause. There is a schoolboy error in their generated service calls.
What's wrong with this picture?:
while (true == userState.IsBusy)
{}
Ignoring the old-school use of true == (not needed in C#), basically their while loop locks up so tight on some machines the IsBusy state is never set. It also means that the application is always running 100% processor use whenever a service call was made.
We have fixed the problem by adding Thread.Sleep(100) in all the service call while loops. e.g.:
while (userState.IsBusy)
{
Thread.Sleep(100);
}
Our app is now working on all Silverlight capable machines (as it should) and is using a lot less processor to boot.
To be fair we are not using the very latest release of sculpture, but it was quite suprising to see such a silly mistake in a commercial package.
I want to know whenever any application starts. Is there a windows message that I can set a hook for to know exactly when that happens?
If polling is not a problem you could use one of the approaches described in the answers to a related question:
C# Process Monitor
The suggested solutions use WMI or Windows audit process tracking mechanism.
The first message sent to new windows is WM_NCCREATE. But this has nothing to do with the process itself, which is what I suspect you're asking? By definition 'window messages' will start to arrive only after you create a window (using CreateWindowEx or whatever), but that can happen long after the process has started.
You don't say what language/framework you're using. In VC++ and the like you can just use whatever passes for the WinMain function. For VB it would be a Main function in a module.