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.
Related
So for work they have me writing a simple program for tracking employee efficiency within their workflow (things like using keyboard shortcuts, window locations, how often they need to look stuff up). Currently we want to track the 'F5' key (brings up next work item), 'Alt+Tab' (changes windows), 'Ctrl+V' (paste), but may be expanded as they find there are more shortcuts or things they want to track.
Note We are on windows 7, and using c# to write the tracking program.
In order to do this I wrote a low-level hooking library to capture the chosen keystrokes, send off the message down the hook chain and then add a note to a db that the key was used. The hooking library works great in All web browsers and most normal programs (except we don't actually care about browsers so we ignore everything done in them).
The issue is that the application that they use for managing their work (the program we actually care about tracking) some how stops our hooks from hooking and I do not know how. The application in question is TA2000 Desktop.
I know that with the way hooks work if an application fails to call callnexthook() within the LowLevelHooksTimeout period that the system kills the hook. So figuring maybe TA2000 was just taking to long or something I bumped up the timeout to 30 seconds (yes I know this is significantly more time than a hook should even need) but this had no effect.
The next thing I tried was implementing a tracking system based on the Raw Input API. And once again the tracking tracks on browsers, Microsoft office, notepad, and all the other programs I opened except it still is unable to track key press in TA2000. This really surprised me because according to MSDN
An application does not have to detect or open the input device.
An application gets the data directly from the device, and processes the data for its needs
An application can distinguish the source of the input even if it is from the same type of device. For example, two mouse devices.
So if I am getting the data directly from the device how is TA2000 preventing me from also getting the key press?
The last thing I could think of trying was using dll injection on TA2000 to inject a hook. However this method seems risky because It is something neither I nor any other developer here has any experience with and the application we want to track is operation critical so messing it up can not happen and injecting code into its memory space seems like a good way to mess things up.
If someone could explain how TA2000 could be stopping me from tracking keystrokes and how to beat it or point me in a good direction I would be very appreciative.
p.s. This felt questionable as an appropriate question for the SO format but it also feels specific enough to be a viable question. So sorry if this is not a good question but I am at my wits end with this.
This financial software package is secured to prevent snooping. Running the key logging software as Administrator appears to fix this specific problem. The security was identified initially using Sysinternals' Process Explorer, which is a great starting point for unexpected problems like this.
The application uses Xamarin.Android, which may be a big problem in itself. The problem is that sometimes it just quits (process is being terminated) and there's nothing in the log that can be associated with it. (although I guess that it's related to running out of memory, but I can't yet prove it — according to DDMS, most of the times all is OK, and if Xamarin.Android uses another pool of memory, then I don't know how to measure it)
I've searched the code base for "Environment.Exit" and, of course, didn't found anything.
What are the options for finding the culprit of such thing?
You could try to use the garbage collector by yourself. Just run
Runtime.getRuntime().gc();
The Runtime instance has also a method to read the free memory space. So you could figure out by yourself whether it's a memory problem.
EDIT:
Oh I read that Xamarin uses the C# language. But I'm quite sure that C# has similar methods.
When you say log, are you referring to an application log, or the device log?
When tracking down these sorts of bugs, I've always found aLogCat invaluable.
I open it, clear all the current logs, then use my application up to the point where it crashes. Then I quickly go back to aLogCat, pause it and scroll up to where the error is - it's usually found in the nearest red/orange blocks.
There's a blog post here about how I found attributes left out by the Xamarin linker using this method.
So I'm trying to speed up our applications startup times -- and I've identified a major bottleneck to work on. Each of our webservice client classes takes forever and a day to instantiate. Some investigation revealed this is entirely due to the SoapHttpClientProtocol running GenerateXMLMappings. I started searching for information on this and found this SO post Slow SoapHttpClientProtocol constructor
I was ready to sound the trumpets since my issues mirrored what was talked about there to the letter. I went through every step listed in the first post to use sgen to pre-generate a serializer dll, and then removed the various tags from the code and built that into a normal dll which I referenced in the applciation as a normal reference (as opposed to a web reference). However after all this, I don't see any difference when profiling the application. Tons of time is still soaked up doing GenerateXMLMappings as part of the SoapHttpClientProtocol constructor.
I have verified that it is in fact using my custom webservice client dll. I have also verified that it is at least looking for the XmlSerializers dll (if I do not include the file I can see a filenotfound is spit up about it).
Does anyone have detailed info about how the SoapHttpClientProtocol constructor decides what it needs to do? This is a really frustrating problem because the whole process seems to be blackboxed with no good way to see what is actually going on internally.
Thanks in advance for any help -- I'm completely against a wall on this one.
I hit this every so often. I'll be happy to guess, but guesses are usually wrong.
To find what the problem really is I just run the app under the IDE and pause it a few times while it's being slow, to see what it's doing. That's this technique.
OK, here are the guesses, which I've seen but for you are probably wrong.
Fetching strings from resources during load.
Notifications gone mad while building data structure.
Initializing 3rd-party grids/controls, even with empty data.
Parsing/Writing XML more than you thought.
Zipping/Unzipping more than you thought.
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.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm starting to think that I should ditch Windows WF in favor of something simpler. I don't necessarily need to pause workflow execution for extended periods of time and restore them later. I would like a simple state machine framework that does have basic suspend / resume / abort (without serialization), however.
I've downloaded the Stateless framework from Google Code and am going to start playing with it, but would love to hear what the other .NET programmers out there are using.
EDIT Stateless seems really simple to implement, but I do wonder if it's the right thing for a candy machine. In automation, I always feel conflicted about how state machines should be used. Although I use the term "state machine", I do so loosely because I use it more like a flow chart. Instead of using states to represent the current mode a machine is in, I use it to execute functions. So in this case with Stateless, I'd actually be using the transition from one state to the next as the mechanism for calling functions in my candy machine's controller. Thoughts?
As I work through this, I'll try to list some of the things I'm finding. Most will likely be a bit superficial from an analysis standpoint (especially since I'm new to both frameworks), but hopefully it will help someone out.
Stateless
Pros
open source
syntactically concise and easy to read
pretty good examples in the mercurial repo on google code
I can translate my UML state diagram into code using stateless very quickly.
state maintenance is very simple -- I can add and remove with ease. Extension methods allow me to configure the states on separate lines, so I can comment out the triggers or actions that I don't want to use.
passing data to/from state machine is easy and you can do it however you wish in code-behind.
likewise, state machine can update GUI in a variety of ways. Right now, I'm modifying data via an interface, and then the GUI uses a timer to update its elements. I could also probably use a BackgroundWorker to do this.
I've just started to use substates for handling my GUI, which needs to manage various states like Running, Paused, Aborted, and Idle. The Paused state has substates because the user can pause the system in a variety of ways, but the resume triggers are specific to the way in which they were paused. I love being able to manage my GUI's enabling / disabling and tooltips by using a lightweight state machine framework.
Cons
no built-in mechanisms for pause, resume, abort
only one developer supporting the project. I did get assistance with a problem I recently ran into, however.
potential for misuse if you're not careful. I implemented the state machine framework improperly on my first attempt. It worked great for months, and then eventually it died when I ran a very long-running process. It turns out I was causing the state handlers to stack up and I had a stack overflow condition.
Windows Workflow Foundation
Pros
graphical approach to designing the workflow
support persistence, pausing, resuming, aborting workflows
MS probably has a big team of programmers to support this
GUI makes it really easy to disable / re-enable activities
Cons
graphical approach to designing the workflow hides the fact that this thing is pretty complex
in order to use persistence and get pause / resume / abort, you have to install and set up a "persistence service", something I've yet to figure out how to get working. I can set up the SQL database fine, but at runtime I get a bunch of errors I don't understand.
because it's from MS, you don't know if it'll be around very long or get completely dropped.
error handling is a little weird because you can either use code behind or a FaultHandler
passing data from WF to your main app is complicated and requires something like WCF (another technology I don't have enough time to learn adequately right now), or use the ExternalDataExchange interface.