We Keep Coding

Might GC.Collect() be warranted in this particular case?

Disclaimer: Yes, I know that the general answer to whether or not to use GC.Collect() is a resounding "NO!". This is the first time in several years of programming that I ever consider using it at all.
Well then, here's the situation: We have developed a C# scripting tool based on the Microsoft.CodeAnalysis.CSharp.Scripting libraries (v3.6.0). It's a Winform GUI with editor etc., not unlike others out there. We use it for the validation of integrated circuits, meaning that its primary task is interfacing lab equipment such as power supplies, pattern generators, meters and the like. For the communication to said instruments we predominantly rely on National Instrument's VISA framework, albeit not exclusively. Some devices are controlled directly via DLLs from their respective manufacturers. In general, this system is working beautifully and by now it is successfully used by quite a lot of design engineers who do not know the first thing about the intricacies of .NET and C#.
At this point I should explain that the user can simply write a method (i.e. on "top-level") and then execute it. The Roslyn-part behind this is that the input is fed to CSharpScript.Create() and then compiled. The execution of a method is done via Script.ContinueWith("method name"). Inside of such a method the user can construct an object like, say, new VISA("connection string"), which connects to the device and then communicate with the device via this object. Nothing forces him or her to care about disposing the object (i.e. closing the connection).
Now, the problem is this: recently, very sporadic crashes of the GUI application have occurred with no feedback at all from the system - the form just closes and that's it. By trial-and-error we are currently 99% sure that if all connection objects are explicitely disposed within a method, the crashes do not occur. So, rewriting the method to something like this fixes the problem:
using(var device = new VISA("connection string"))
{
device.Query("IDN?");
}
The reason why I look into the GC's direction at all is that there is no discernible correlation to any actions from the user. The guys might run such methods for an hour without a problem and then, when scrolling in the editor, when no method is currently being executed, the GUI closes without comment. And that's why I'd like to get some input from people more knowledgeable about Roslyn and the GC:
Are there known issues with this scripting library and GC? (I would very much assume that there aren't)
Since the explicit disposal of objects seem to prevent the issue, might this be one of the extremely scarce situations where the use of GC.Collect() might be warranted? (admittedly, I could not yet test whether that also prevents the problem thanks to of home office)
Any ideas what can cause a .NET application to crash without any kind of feedback and how to obtain more information about such a crash? (the scripting engine is a separate DLL, as are the device drivers; the GUI only handles the graphics)
I am fully aware that this is a rather vague description of the problem with very little source code. This is due to the fact that the application comprises of quite a lot of source code and I have no idea what might be relevant here. Also, all namespaces in the above text refer to Microsoft.CodeAnalysis.CSharp.Scripting, except for VISA, which is self-defined. Obviously, I will gladly answer any follow-up questions for getting to the bottom of this.
Thanks in advance.

Short answer: No. It's not only not warranted, it's completely missing the actual issue.
Further explanation: #canton7 instantly hit the nail on the head when writing
I'd argue that your application shouldn't crash even if a finalizer does end up being called
The root issue hid inside a 3rd party DLL in form of an, at the very least, suboptimal implementation of IDisposable. Once I zoomed in on that, it was rather easy to produce a workaround for that.
My original question is so very misguided that I'd like to state the one that I should have asked:
How do I trace a crash of my C# application when my application's logging does not show anything?
This question has been answered comprehensively in a number of posts. In my case, the crash could be seen in the Windows event log.

SslStream responds differently when accessed as COM object

I am working with an on a project where the bulk of the code is C++. The shop is migrating to C# in the long run, so where possible we are making new code in C# and exposing to C++ via COM.
I have wrapped an System.Net.Sockets.SslStream and a little bit of other functionality in a COM object that is intended to send and then receive messages. When calling the functions on this class from a test C# program I am able to send and receive messages without issue. Making the same calls, which are exposed via COM, seems to work as well, except I cannot receive data immediately after I send.
From the C# test data sends and receives quite quickly and I get the responses I should. From C++ I always get timeout errors. The data in the functions making the call to Read is identical in the C# test and from the C++ program. Much of the state in the SslStream is identical. Just after the write call and before the Read the only differences appear to be, several handles and what appear to be memory addressest, but I assume those are not important. At this same time I noticed that in an item called 'base', then inside an item called 'InnerStream', then inside 'System.Net.Sockets.NetworkStream' there is a property called 'DataAvailable'. This is true in the C# test where it works and false in the C++ program where it fails. I am not aware of any meaningful difference between these project beyond what I have described.
I can provide further details about troubleshooting or snippets of code. I have not included code here because tjust the pieces related to the problem would still be immense. I hope there is some kind of magic answer as to what is going on, however the error is almost certainly in depth and very specific. I would appreciate anything that provides insight on further troubleshooting steps.
What kinds of complications does calling C# though COM impose that I may not have taken in account?
Where did the other sides message go if not into the SslStream buffer?
Where should I be looking?

I have discovered the answer, and it is unrelated to COM, C#, C++ and instead has to do with the formatting of the message being sent between the systems involved. The other system uses an extra carriage return to indicate the end of the message. When missing the remote system simply stops responding until another SSL session is started.
At a previous point in the project I was including an extra line break at the end of messages sent to the server. I had copied one of these messages to produce my entirely c# test. Several times I also took the messages being sent from both codebases and put them into a merge/diff viewer. I never noticed this difference because I had disabled white space matching.
From now on when I compare raw output to other raw output, I will make sure that none of my tools will hide differences from me.

How to hook NTShutdownSystem in C# in order to differentiate between shutdown and reboot

unfortunatly, when you listen to WM_QUERYENDSESSION, you do not get the information if the user has requested a reboot or a shutdown. This is really bad design, but it's the way Windows is, so I was thinking of hooking the call to NTShutdownSystem, which gets a parameter telling the system to perform a reboot or to shutdown.
The question is: how can this actually be achieved in C#? I want to get some kind of hook that I can use to determine the parameters passed to NTShutdownSystem, and then save that information. After that, I want to call the "real" NTShutdownSystem the way it was intended by the user.
Do you have any sample code illustrating this?

The reason why WM_QUERYENDSESSION does not give a shutdown reason is that the user may just be logging out at that time, rather than shutting down the system.
This generally falls under the category of kernel level hooking and has generally not been considered a good thing as it can influence stability of the system. Most of them are written in C or C++, and generally have to go to a lot of effort to perform the hook across all the programs that are executing - e.g. hooking the routines at program load-time.
This is not a trivial, but there are some frameworks that have been written to help with trying to hook routines like this using managed code (e.g. C#)
The next question to ask is why do you care?
edit NTShutdownSystem is invoked very late in the shutdown process - at that point you probably have no UI and no way of doing anything. I would recommend intercepting ExitWindowsEx, InitiateShutdown, InitiateSystemShutdown and InitiateSystemShutdownEx - I don't know if some of them are called by the other, but you should probably only record the reason and then react to the reason in the WM_QUERYENDSESSION code of your standard app.

How is application virtualization implemented?

I am trying to understand how software like App-V and sandboxie (http://www.sandboxie.com/) work. But for the life of me, I can't think of anything that could make this possible. How do they intercept API calls and trick the target software? If someone would say that it's just magic and pixie dust, I would believe them. Seriously though, are there any white papers that discuss solutions to this problem?
If this is possible on the CLR level then that would be good but I'm willing to go native if I have to.

Sandboxie does it by essentially injecting code into core Windows API, the same way a virus would (which is why Vista x64 prevents this behaviour, and why Sandboxie doesn't work on that OS).
Here is a project explaining API hooking. I learned how all this work by studying the sourcecode for Metamod:Source (used for SourceMod for CounterStrike:Source :) )

I don't know how MS did it, but here is the basic theory of one way to do it ...
What you want to do is hook into the system calls (similar to chaining into interrupt).
System call occurs.
Your custom intercept gets executed.
If this syscall does not need special processing, continue on. Otherwise it needs special processing and go to step 4.
Get the stack pointer, instruction pointer and all that jazz from the stack, and build a new stack frame to send you back to your custom code in user-land.
Do your massaging of data and paths and stuff in user land. This way if the underlying OS changes, this code does not have to be updated [as frequently].
After all the data massaging, execute the system call again.
Your custom interrupt executes again, but it should detect that you are calling from your user-land helper layer and pass the call on through. Some stack frame manipulation may be required to set up proper return addresses.
Regular system call executes.
When the system call returns, the stack frame should should send you back to your regular program flow.
Hope this helps.

Check out the Wikipedia page on X86 Virtualization which discusses both software virtualization (early VMWare, Wine, Sandboxie and to an extent App-V) and the more modern hardware virtualization (Hyper-V, VMWare, others).
I'm assuming you're looking specifically for software virtualization as by using .NET (or any CLR) you're already abstracting yourself away from the CPU architecture to an extent, especially with the 'AnyCPU' target.

Listen for events in another application

Suppose I have two applications written in C#. The first is a third party application that raises an event called "OnEmailSent".
The second is a custom app that I've written that I would like to somehow subscribe to the "OnEmailSent" even of the first application.
Is there any way that I could somehow attach the second application to an instance of the first application to listen for "OnEmailSent" event?
So for further clarification, my specific scenario is that we have a custom third party application written in c# that raises an "OnEmailSent" event. We can see the event exists using reflector.
What we want to do is have some other actions take place when this component sends an email.
The most efficient way we can think of would be to be able to use some form of IPC as anders has suggested and listen for the OnEmailSent event being raised by the third party component.
Because the component is written in C# we are toying with the idea of writing another C# application that can attach itself to the executing process and when it detect the OnEmailSent event has been raise it will execute it's own event handling code.
I might be missing something, but from what I understand of how remoting works is that there would need to be a server defining some sort of contract that the client can subscribe to.
I was more thinking about a scenario where someone has written a standalone application like outlook for example, that exposes events that I would like to subscribe to from another application.
I guess the scenario I'm thinking of is the .net debugger and how it can attach to executing assemblies to inspect the code whilst it's running.

In order for two applications (separate processes) to exchange events, they must agree on how these events are communicated. There are many different ways of doing this, and exactly which method to use may depend on architecture and context. The general term for this kind of information exchange between processes is Inter-process Communication (IPC). There exists many standard ways of doing IPC, the most common being files, pipes, (network) sockets, remote procedure calls (RPC) and shared memory. On Windows it's also common to use window messages.
I am not sure how this works for .NET/C# applications on Windows, but in native Win32 applications you can hook on to the message loop of external processes and "spy" on the messages they are sending. If your program generates a message event when the desired function is called, this could be a way to detect it.
If you are implementing both applications yourself you can chose to use any IPC method you prefer. Network sockets and higher-level socket-based protocols like HTTP, XML-RPC and SOAP are very popular these days, as they allow you do run the applications on different physical machines as well (given that they are connected via a network).

You can try Managed Spy and for programmatic access ManagedSpyLib
ManagedSpyLib introduces a class
called ControlProxy. A ControlProxy is
a representation of a
System.Windows.Forms.Control in
another process. ControlProxy allows
you to get or set properties and
subscribe to events as if you were
running inside the destination
process. Use ManagedSpyLib for
automation testing, event logging for
compatibility, cross process
communication, or whitebox testing.
But this might not work for you, depends whether ControlProxy can somehow access the event you're after within your third-party application.
You could also use Reflexil
Reflexil allows
IL modifications by using the powerful
Mono.Cecil library written by Jb
EVAIN. Reflexil runs as Reflector plug-in and
is directed especially towards IL code
handling. It accomplishes this by
proposing a complete instruction
editor and by allowing C#/VB.NET code
injection.

You can either use remoting or WCF. See http://msdn.microsoft.com/en-us/library/aa730857(VS.80).aspx#netremotewcf_topic7.

What's the nature of that OnEmailSent event from that third party application? I mean, how do you know the application is triggering such an event?
If you are planning on doing interprocess communication, the first question you should ask yourself is: Is it really necessary?
Without questioning your motives, if you really need to do interprocess communication, you will need some sort of mechanism. The list is long, very long. From simple WM_DATA messages to custom TCP protocols to very complex Web services requiring additional infrastructures.
This brings the question, what is it you are trying to do exactly? What is this third party application you have no control over?
Also, the debugger has a very invasive way of debugging processes. Don't expect that to be the standard interprocess mechanism used by all other applications. As a matter of fact, it isn't.

You can implement a similar scenario with SQL Server 2005 query change notifications by maintaing a persistent SqlConnection with a .NET application that blocks until data changes in the database.
See http://www.code-magazine.com/article.aspx?quickid=0605061.

also WM_COPYDATA might be possible, see https://social.msdn.microsoft.com/Forums/en-US/eb5dab00-b596-49ad-92b0-b8dee90e24c8/wmcopydata-event-to-receive-data-in-form-application?forum=winforms
I'm using it for similar Purose (to notify that options have been changed)
In our C++/Cli-scenario (MFC-)programs communicate vith WM_COPYDATA with Information-String in COPYDATASTRUCT-Member lpData
(Parameterlist like "Caller=xyz Receiver=abc Job=dosomething"). also a C#-App can receive WM_COPYDATA-messages as shown in the link. Sending WM_COPYDATA from C# (to known Mainframe-Handle) is done by a cpp/cli-Assembly, (I didnt proove how sending WMCOPYDATA can bei done in C#).
PS in Cpp/Cli we send AfxGetMainWnd()->m_hWnd as WPARAM of WMCOPYDATA-Message and in C# (WndProc) m.WParam can be used as adress to send WM_COPYDATA