Crashing occurs when closing and opening a VI

[Eric1977]

Bill,

Now that you say that, yes. I'm using the FileSystemWatcher (mscorlib.dll) to watch files as they come in so I can consume them as they are placed in a directory.

I also remember a post about the GC.Collect method(?) needing to be called for something as .NET doesn't do proper garbage collection in LV - or something like that - so that will force it to occur. I am not doing that when I destroy the watcher.

Eric

[rolfk]

That FileSystemWatcher is a very good suspect. The GC Collect shouldn't be necessary to make things safe. That is more related to callback VIs staying locked as there is still a .Net context referencing them and your FileSystemWatcher of course will use callback VIs (or did you rather register the .Net Event as a LabVIEW user event, which works too)?

In any case using .Net events is always a bit tricky since you often have a .Net side of the event that needs to be explicitly destroyed with a Destroy() or Close() call and also a LabVIEW side of the event that needs to be properly closed too. In the case of events registered as user events you have in fact the Unregister first and then the LabVIEW Refnum close for the event itself. And correct order of closing/deallocation can matter here for sure!

[Eric1977]

Bill,

To make sure I understand, I should:

1. Dispose of the File System Watcher
2. Close the Reference to the watcher
3. Unregister for the Events REfrum
4. Destroy the User Event
5. Unregister the Events from the Event Callback Refrum

[billko]

---

@Eric1977 wrote:

Bill,

To make sure I understand, I should:

1. Dispose of the File System Watcher
2. Close the Reference to the watcher
3. Unregister for the Events REfrum
4. Destroy the User Event
5. Unregister the Events from the Event Callback Refrum

---

I think rolfk is much more qualified to answer this than me.  Sorry!  😞

[rolfk]

As to the order of how to dispose things I think the example from the linked article should be ok.

1) Unregister user event registration refnum

2) Destroy User event

3) FileSystemWatcher.Dispose()

4) Close FileSystemWatcher

5) Unregister Event Callback refnum

[Eric1977 · Accepted solution]

rolfk,

The Access Violations came from a Access Database that I was using for a test db. The connection string looked good based on what I saw on ConnecctionStrings.com. Once I switched it over to SQL Server (which we have a sandbox area where we can test things like this) the access violations went away.

Have you, or anyone else, heard of these violations happening to Access Databases? I have Office 365 with Access installed on my PC. Curious is all.

[rolfk]

---

@Eric1977 wrote:

Have you, or anyone else, heard of these violations happening to Access Databases? I have Office 365 with Access installed on my PC. Curious is all.

---

I haven't used Access in probably 20 years. It's not really a database in many aspects. And office applications through ActiveX interface are troublesome at best in respect to mixing and matching between 32-bit and 64-bit. With them nowadays being almost exclusively installed as 64-bit version, you are bound to run into trouble if you try to access them from 32-bit application such as many LabVIEW installations still are.

Not that it couldn't be done. (D)COM, which is at the base of ActiveX is perfectly capable of bridging that gap (if the component is properly registered to do that) because of its inherent almost fully transparent data marshalling through out of process invocation of the ActiveX server component. But that requires a strict discipline in developing and registering such components, and that is something almost nobody does anymore in the modern days of "everything is .Net", especially from Microsoft who have all their bets 120% on .Net and are more than happy to let ActiveX drop from the radar ASAP.

[Eric1977]

Never even gave the bitness a thought but sounds like that very well could be the issue. And Microsoft's continued massaging.

I'll put my post as the solution about Access being the culprit. I'll have to remember that for next time. Have a good 4th of July weekend.