Exception_Access_Violation when closing DOORS

Im unsure as to the reason why but lately I will randomly get these Exception_Access_violation errors when I go to close my DOORS program at the end of the day.

DXL Interaction Window


-R-E- DXL: <config/baseWindowCallbacks.inc:268> An unexpected error has occurred: doors.exe caused an EXCEPTION_ACCESS_VIOLATION in module doors.exe at 0000000059C3F283

Backtrace:
    <config/baseWindowCallbacks.inc:278> 
 

 

Diagnostic Log


DOORS: **** Translating a structured exception ****
DOORS: Version 9.6.1.11, build number 96835, built on May 31 2018 01:24:28.
DOORS: Microsoft Windows 8
DOORS: DOORS: 39 percent of memory is in use.
DOORS: There are 16654936 total Kbytes of physical memory.
DOORS: There are 10062408 free Kbytes of physical memory.
DOORS: There are 19145304 total Kbytes of paging file.
DOORS: There are 10617796 free Kbytes of paging file.
DOORS: There are ffffff80 total Kbytes of virtual memory.
DOORS: There are fdafd094 free Kbytes of virtual memory.


DOORS: Exception timestamp: 01/08/2019 at 15:03:25
DOORS: doors.exe caused an EXCEPTION_ACCESS_VIOLATION in module doors.exe at 0000000059C3F283
DOORS: 0x007ff759c3f283 doors.exe
0x007ff759c3e041        doors.exe
0x007ff75a3d3d1a        doors.exe
0x007ff75a3d3bd8        doors.exe
0x007ff75a3cdaa2        doors.exe
0x007ff75a91e627        doors.exe
0x007ff75a91daf6        doors.exe
0x007ff75a3d3ec2        doors.exe
0x007ff75a3d3bd8        doors.exe
0x007ff759c18bed        doors.exe
0x007ff759c191bb        doors.exe
0x007ff759c188f5        doors.exe
0x007ff759c18a2d        doors.exe
0x007ff75b29c09d        doors.exe
0x007ff75b059f15        doors.exe
0x007ff75b05d240        doors.exe
0x007ff75b06f983        doors.exe
0x007ff75b3ac428        doors.exe
0x007ff75b40f4fb        doors.exe
0x007ff75ab29975        doors.exe
0x007ff84d106d41        USER32.dll,     CallWindowProcW()+00001217 byte(s)
0x007ff84d106a1c        USER32.dll,     CallWindowProcW()+00000412 byte(s)
0x007ff84d1104d3        USER32.dll,     IsWindowVisible()+00000419 byte(s)
0x007ff84e8be6b4        ntdll.dll,      KiUserCallbackDispatcher()+00000036 byte(s)
0x007ff84bc91164        win32u.dll,     NtUserMessageCall()+00000020 byte(s)
0x007ff84d1046f6        USER32.dll,     GetWindowTextW()+00002022 byte(s)
0x007ff84d103ed2        USER32.dll,     UpdateWindow()+00000242 byte(s)
0x007ff848e15c0a        uxtheme.dll,    HitTestThemeBackground()+00029178 byte(s)
0x007ff848e1f342        uxtheme.dll,    Ordinal96()+00000594 byte(s)
0x007ff848e14a34        uxtheme.dll,    HitTestThemeBackground()+00024612 byte(s)
0x007ff848e134e1        uxtheme.dll,    HitTestThemeBackground()+00019153 byte(s)
0x007ff84d104414        USER32.dll,     GetWindowTextW()+00001284 byte(s)
0x007ff75ab29702        doors.exe
0x007ff84d106d41        USER32.dll,     CallWindowProcW()+00001217 byte(s)
0x007ff84d106a1c        USER32.dll,     CallWindowProcW()+00000412 byte(s)
0x007ff84d1104d3        USER32.dll,     IsWindowVisible()+00000419 byte(s)
0x007ff84e8be6b4        ntdll.dll,      KiUserCallbackDispatcher()+00000036 byte(s)
0x007ff84bc91164        win32u.dll,     NtUserMessageCall()+00000020 byte(s)
0x007ff84d1046f6        USER32.dll,     GetWindowTextW()+00002022 byte(s)
0x007ff84d103ed2        USER32.dll,     UpdateWindow()+00000242 byte(s)
0x007ff848e15c0a        uxtheme.dll,    HitTestThemeBackground()+00029178 byte(s)
0x007ff848e1f034        uxtheme.dll,    GetThemeAppProperties()+00000564 byte(s)
0x007ff848e14a34        uxtheme.dll,    HitTestThemeBackground()+00024612 byte(s)
0x007ff848e134e1        uxtheme.dll,    HitTestThemeBackground()+00019153 byte(s)
0x007ff84d104414        USER32.dll,     GetWindowTextW()+00001284 byte(s)
0x007ff75ab29702        doors.exe
0x007ff84d106d41        USER32.dll,     CallWindowProcW()+00001217 byte(s)
0x007ff84d106713        USER32.dll,     DispatchMessageW()+00000467 byte(s)
0x007ff75ab18d26        doors.exe
0x007ff759c20d09        doors.exe
0x007ff759c0b346        doors.exe
0x007ff759c0ba71        doors.exe
0x007ff84e6e3dc4        KERNEL32.DLL,   BaseThreadInitThunk()+00000020 byte(s)
0x007ff84e893691        ntdll.dll,      RtlUserThreadStart()+00000033 byte(s)

DOORS: **** end of event ****

 

I have saved and closed all modules prior to closing out DOORS 

Could this be the result of a trigger and if so would i be able to tell which trigger is the culprit?

I also end up having to close out the program using the task manager and killing it from there otherwise I click on the X button and it does nothing after the error


MrNiceGuy - Thu Aug 01 18:17:49 EDT 2019

Re: Exception_Access_Violation when closing DOORS
davidcs - Fri Aug 02 09:14:18 EDT 2019

I've been getting this error for at least a year. IT folks at our company don't care about fixing problems so all I can hope for is maybe IBM (or whoever owns DOORS now) will fix it someday.

Re: Exception_Access_Violation when closing DOORS
Costas..Aravidis - Sat Aug 03 04:32:24 EDT 2019

davidcs - Fri Aug 02 09:14:18 EDT 2019

I've been getting this error for at least a year. IT folks at our company don't care about fixing problems so all I can hope for is maybe IBM (or whoever owns DOORS now) will fix it someday.

I do not beleive this is an issue with DOORS, this is an issue with your operating system and the dll C++ libraties. The correct libraties have not been updated in your operating system istallation. It might be that you need to reinstall DOORS as an administrator. 

Re: Exception_Access_Violation when closing DOORS
O.Wilkop - Wed Aug 07 06:41:53 EDT 2019

We're having the same problem since we moved to DOORS 9.6.1.11. 

The diagnostic error log seems to happen whenever you have a lot of modules open and you close a module that has a trigger (even a empty trigger with no code!). It happens kind of randomly upon closing the module through UI or dxl, so we assume it has to do with where the module ends up being in the memory. Our tool experts have contacted IBM and from what I've been told IBM has accepted this problem as a defect.

 

We're currently testing DOORS 9.7 and the problem seems to be gone (or it at least happens a lot less frequently).

Re: Exception_Access_Violation when closing DOORS
davidcs - Wed Aug 07 13:19:01 EDT 2019

O.Wilkop - Wed Aug 07 06:41:53 EDT 2019

We're having the same problem since we moved to DOORS 9.6.1.11. 

The diagnostic error log seems to happen whenever you have a lot of modules open and you close a module that has a trigger (even a empty trigger with no code!). It happens kind of randomly upon closing the module through UI or dxl, so we assume it has to do with where the module ends up being in the memory. Our tool experts have contacted IBM and from what I've been told IBM has accepted this problem as a defect.

 

We're currently testing DOORS 9.7 and the problem seems to be gone (or it at least happens a lot less frequently).

We are current on 9.6.1.11 with plans on moving to 9.7 in the near future so that is good to hear.

Your description of the issue is the same as my experience, I never tied the issue to triggers but most of our projects are using triggers in some capacity.

Re: Exception_Access_Violation when closing DOORS
llandale - Mon Aug 19 16:22:58 EDT 2019

Costas..Aravidis - Sat Aug 03 04:32:24 EDT 2019

I do not beleive this is an issue with DOORS, this is an issue with your operating system and the dll C++ libraties. The correct libraties have not been updated in your operating system istallation. It might be that you need to reinstall DOORS as an administrator. 

Would you mind please elaborating on this, why you believe this is the issue and the solution?

Re: Exception_Access_Violation when closing DOORS
llandale - Mon Aug 19 16:24:26 EDT 2019

O.Wilkop - Wed Aug 07 06:41:53 EDT 2019

We're having the same problem since we moved to DOORS 9.6.1.11. 

The diagnostic error log seems to happen whenever you have a lot of modules open and you close a module that has a trigger (even a empty trigger with no code!). It happens kind of randomly upon closing the module through UI or dxl, so we assume it has to do with where the module ends up being in the memory. Our tool experts have contacted IBM and from what I've been told IBM has accepted this problem as a defect.

 

We're currently testing DOORS 9.7 and the problem seems to be gone (or it at least happens a lot less frequently).

Why do you believe this has to do with triggers?  Are you talking about triggers stored in the module, or perhaps a project level "close-module" trigger, either pre or post?