Anyone on here have access to source? It's hard to generate a self-contained small sample to reproduce this without a lot of effort, but hopefully someone might be able to see what the critical section it's hanging on is for, and suggest whether there's a bug in the dll or at my end...
- PCAN.PNG (9.86 KiB) Viewed 1835 times
it seems as you are calling the PCAN-Basic from within another dll (MxxxBootloader.dll). Are you using critical sections in there? Are you loading the PCAN-Basic dll when the program is terminating (at DetachDll)? There are several possibilities for such a problem, but I think this is more at your end.
Maybe this document is useful for you:
Dynamic-Link Libraries Best Practices
I've no critical sections in my own code. It's a critical section within the PCAN-Basic dll that it's using that's not releasing for some reason.
Do you have source access? What's the critical section object used for? Could there be a race or some such if there's data arriving on the bus just as I call Unitialise, or something like that?
This is the most basic procedure users follow with PCAN-Basic. added to this, it has been used since years mainly in multithreading scenarios. It would be very extrange to have such undetected bug of this kind in the library. Please do the test with any of the sample project: Start debugging (or start the already compiled sample), connect to a channel and start reading messages. Then just click disconnect and connect several times. Please tell us if you see the same problem with it.andrewjb3 wrote:the Initlaize then Uninitialize are being done whilst the app is running.
Please provide us with a minimalistic test project that shows the problem, and we will test it. You can send the files to support[at}peak-system.com, mentioning this post so we can know what it is about.andrewjb3 wrote:Do you have source access? What's the critical section object used for? Could there be a race or some such if there's data arriving on the bus just as I call Unitialise, or something like that?