NightlyBuilds 1.4.23 with EXCEPTION_ACCESS_VIOLATION and hs_err_pid * .log

Usage & Issues
#1

Hi all,
I am trying nightlyBuilds 1.4.23_20201220 (64 bit) on two different machines (one with Windows 7 and one with Windows 10) to write a new device adapter. In both cases, even with a clean installation (without my module), I find a strange thing: when I close the application I find a file hs_err_pid * .log which seems to report an exception. This happens every time I open the hardware configuration wizard.
The log shows the following initial information::

A fatal error has been detected by the Java Runtime Environment:

EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc = 0x00000000187bea36, pid = 23196, tid = 15944

JRE version: 6.0_31-b05

Java VM: Java HotSpot ™ 64-Bit Server VM (20.6-b01 mixed mode windows-amd64 compressed oops)

Problematic frame:

C 0x00000000187bea36

This also happens when I start the application as administrator (otherwise it won’t allow me to save the hardware configuration file).
Has anyone encountered the same problem? Has anyone fixed it?

Thanks in advance,

Salvatore

#2

Can you try 20201224 or later? There have been some changes that may affect this. I’ll test myself later as well.

#3

Hi Salvatore, nice to see you here!

I can confirm the same thing happens with 20200218 nightly build I have been using for a while, except the PC value is different (mine seems to be 0x000000001a78ea36).

I have never noticed this until you pointed it out, nor have I noticed any detrimental effects. Since 1.4.x is not under active development this might be best treated a “no harm, no foul” situation.

Jon

#4

Thanks for your reply Nico.
The most recent version I see in the repository
Index of /~MM/nightlyBuilds/1.4/Windows is 20201220. Where can I find 20201224 or later?

#5

Thanks for your reply and and your welcome, Jon.
My problem is that I am developing a device adapter for Micromanager and the source code I am using (from the Subversion repository Index of /~MM/nightlyBuilds/1.4/Windows) compiles a dll that is not recognized by the micro-manager release (wizard present as unavailable the device adapter) but I solve this problem with the nightly build.
My doubts therefore are:

  • Is there a previous source code repository that allows me to compile a device adapter that is recognized by the current release of micro-manager?
  • Once the device adapter is ready, how can I compile it for the current mirco-manager release?
    Thanks in advance,
    Salvatore
#6

This sounds like a device interface version mismatch between the MM release you have installed and the device adapter DLL you compiled from source. See http://micro-manager.3463995.n2.nabble.com/micromanager-in-c-tp7590030p7590036.html.

See also this post and link contained in it: Writing device adapters for micro-manager 2.0 - #2 by jdeschamps. I understand that essentially nothing about the device adapters changes between 1.4 and 2.0.

#7

Oops, looks like our Windows build machine stopped producing output (and I currently can not reach it). It may take some time to get that back up… I’ll probably will not get to it before Monday, and if it involves setting up a complete new system it may take some time.

#8

I believe the issue to be related to: Crash when adding Aladdin Syringe Pump to Hardware Configuration · Issue #953 · micro-manager/micro-manager · GitHub, which is fixed in the current code in svn (but not yet build by the build machine;).

If you want your code to work with the released version, you need to build using the code that was used to build the released version, for instance by checking out: micromanager2 - Revision 17411: /tags/1.4.22 using a subversion client.

However, the release is very old, and your code will be much more useful for everyone by including it in the Micro-Manager source code repository, so that it will be available in all future builds of Micro-Manager (at least, once the build process is restored;)

#9

Thank you very much Nico for your reply and your suggestions.
I will checkout with the svn you indicated to me.Of course, as soon as the adapter device works, I will make it available for the Micro-Manage source code repository.
I take this opportunity to wish the whole community a Happy New Year!

Salvatore

#10

Thanks Jon,
but it should not depend on the dll I compiled, as the exception occurs even when with clena installation on different machines.

#11

I view what you described as two separate issues:

  1. Exception when MM shuts down if the HCW has been launched. This happens whether or not your new device adapter is present. Nico suggests this is hopefully fixed in newer builds (once the build server is restored) but I don’t see it as a showstopper regardless. It seems this bug has been present for at least since 18-Feb-2020 and since then I have updated device adapters and I’m pretty sure others have added new device adapters.

  2. Your newly compiled device adapter DLL isn’t recognized by the installed binary of MM. I suggest the most likely culprit is a device interface version mismatch. Easiest approach in my experience is to update the binary if needed, but if you can’t update the binary then you can compile your DLL with an older device interface version (by using your SVN client to update the working copy – except your new device adapter – to match the date of the MM binary). The SVN timeline is helpful in finding that date.

I could be completely off-base; it wouldn’t be the first time. But maybe you could clarify further if so.

#12

hi Jon.
You and Nico have perfectly clarified my doubts.
I agree that the current build bug is not a showstopper. Also, thanks to your suggestions, I am able to compile perfectly functioning device adapters, at least so far. At the moment I am using the nighttly build without worrying about the exception, but later I will also try the previous version.
You have fully hit the problem. Thanks for your help.

#13

Build machine is back up. A new nightly build of 2.0 is up already, and 1.4 will be available within half an hour or so. Please do report back if the Exception Access Violation continues.

1 Like
#14

I’m sorry Nico,
but the current version (installed from MMSetup_64bit_1.4.23_20210105.exe) keeps giving me the same problem

A fatal error has been detected by the Java Runtime Environment:

EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000010feea36, pid=8344, tid=5124

JRE version: 6.0_31-b05

Java VM: Java HotSpot™ 64-Bit Server VM (20.6-b01 mixed mode windows-amd64 compressed oops)

Problematic frame:

C 0x0000000010feea36

#15

Do you get a similar error with MM 2.0? The java code of 1.4 is no longer maintained, so unless someone proposes a fix for this (relatively innocuous) bug, it will not be fixed. If the same problem is present in 2.0, I’ll open a ticket on github (or you can do so yourself).

#16

Hi Nico,
I finally got to try MM 2.0 and I can confirm that here too I have the same behavior.

#17

See: Crash on quit after opening Hardware Configuration Wizard · Issue #957 · micro-manager/micro-manager · GitHub

Removing mmgr_dal_Omicron.dll will likely solve the issue.

#18

This crash has been fixed as of tonight’s build, see Crash on quit after opening Hardware Configuration Wizard · Issue #957 · micro-manager/micro-manager · GitHub

#19

thank you very much Nico.

Salvatore