Hello all,
I got a problem from a customer, when PcVue was running, he launched lonmaker to configure some IO, then PcVue's main window disappeared, but the sv32 and hds processes were still alive when check the task manager.
We have the logs in "sv32.exceptions.log". It happened several times, but last Saturday we tried a lot and failed to reproduced it.
Project info: 1 PcVue station with more than 1000 Lonworks DDC, more than 100000 IO, the response time is very fast: within 2s. 🙂
All the logs are nearly the same, but the different is "Function = 1038" sometimes.
Could we know why with the logs below? Thanks a lot.
-----------------------------------------------------------------------------------------------
######## EXCEPTION: 0xC0000005 at address: 0x00E7BB05: ACCESS VIOLATION read attempt to address 0x00000070
2013/10/17,15:53:39.071, 9.0 Vba (20/10/09), d:TechnovatorTechVue 9.0USRIFC
Message Dump processed:
Type = Mail
Function = 1039
Source manager = Variable
Destination manager = Variable
Source station = 1
Destination station = 1
1: 0 _LocalServer::NackValue_NSCOM +30 bytes
1: Decl: _LocalServer::NackValue_NSCOM
1: Line: ..VARvlclsrv.cxx(521) +3 bytes
1: Mod: svvar, base: 00dd0000h
1: 1 CLnsNode::StopMonitoring +188 bytes
1: Decl: CLnsNode::StopMonitoring
1: Line: ..VARvlnsnode.cxx(1384) +0 bytes
1: Mod: svvar, base: 00dd0000h
1: 2 CLnsNetwork::StopMonitoring +40 bytes
1: Decl: CLnsNetwork::StopMonitoring
1: Line: ..VARvlnsnet.cxx(1930) +0 bytes
1: Mod: svvar, base: 00dd0000h
1: 3 CAppDeviceHandler::CheckState +82 bytes
1: Decl: CAppDeviceHandler::CheckState
1: Line: ..VARvlnsnet.cxx(2438) +0 bytes
1: Mod: svvar, base: 00dd0000h
1: 4 CAppDeviceHandler::OnParentAttachmentChange +92 bytes
1: Decl: CAppDeviceHandler::OnParentAttachmentChange
1: Line: ..VARvlnsnet.cxx(2421) +0 bytes
1: Mod: svvar, base: 00dd0000h
1: 5 CRouterDeviceHandler::OnParentAttachmentChange +262 bytes
1: Decl: CRouterDeviceHandler::OnParentAttachmentChange
1: Line: ..VARvlnsnet.cxx(2266) +19 bytes
1: Mod: svvar, base: 00dd0000h
1: 6 CRouterDeviceHandler::OnParentAttachmentChange +185 bytes
1: Decl: CRouterDeviceHandler::OnParentAttachmentChange
1: Line: ..VARvlnsnet.cxx(2262) +19 bytes
1: Mod: svvar, base: 00dd0000h
1: 7 CRouterDeviceHandler::OnAttachmentChange +28 bytes
1: Decl: CRouterDeviceHandler::OnAttachmentChange
1: Line: ..VARvlnsnet.cxx(2221) +0 bytes
1: Mod: svvar, base: 00dd0000h
1: 8 CNSDHandler::OnRouterAttachmentChange +51 bytes
1: Decl: CNSDHandler::OnRouterAttachmentChange
1: Line: ..VARvlnsnet.cxx(2067) +0 bytes
1: Mod: svvar, base: 00dd0000h
1: 9 CLnsNetwork::OnAttachment +146 bytes
1: Decl: CLnsNetwork::OnAttachment
1: Line: ..VARvlnsnet.cxx(1882) +0 bytes
1: Mod: svvar, base: 00dd0000h
1: 10 _LnsFamily::OnAttachment +98 bytes
1: Decl: _LnsFamily::OnAttachment
1: Line: ..VARvlnsfml.cxx(2058) +0 bytes
1: Mod: svvar, base: 00dd0000h
1: 11 VarRcvMsg +17343 bytes
1: Decl: VarRcvMsg
1: Line: ..VARvarmain.cxx(3009) +0 bytes
1: Mod: svvar, base: 00dd0000h
1: 12 VarApp::RcvMsg +18 bytes
1: Decl: VarApp::RcvMsg
1: Line: ..VARvarproc.cxx(171) +11 bytes
1: Mod: svvar, base: 00dd0000h
1: 13 WinApp::DispatchMsg +129 bytes
1: Decl: WinApp::DispatchMsg
1: Line: winapp.cxx(925) +0 bytes
1: Mod: svkrnl, base: 00760000h
1: 14 WinApp::OnMessagePCVUE +371 bytes
1: Decl: WinApp::OnMessagePCVUE
1: Line: winapp.cxx(199) +0 bytes
1: Mod: svkrnl, base: 00760000h
1: 15 Ordinal5163 +1582 bytes
1: Decl: Ordinal5163
1: Mod: MFC42, base: 754e0000h
1: 16 Ordinal6374 +44 bytes
1: Decl: Ordinal6374
1: Mod: MFC42, base: 754e0000h
1: 17 Ordinal1109 +167 bytes
1: Decl: Ordinal1109
1: Mod: MFC42, base: 754e0000h
1: 18 Ordinal1578 +62 bytes
1: Decl: Ordinal1578
1: Mod: MFC42, base: 754e0000h
1: 19 Ordinal1579 +77 bytes
1: Decl: Ordinal1579
1: Mod: MFC42, base: 754e0000h
1: 20 LoadCursorW +19701 bytes
1: Decl: LoadCursorW
1: Mod: USER32, base: 77e10000h
1: 21 LoadCursorW +20102 bytes
1: Decl: LoadCursorW
1: Mod: USER32, base: 77e10000h
1: 22 TranslateMessageEx +269 bytes
1: Decl: TranslateMessageEx
1: Mod: USER32, base: 77e10000h
1: 23 DispatchMessageA +15 bytes
1: Decl: DispatchMessageA
1: Mod: USER32, base: 77e10000h
1: 24 Ordinal5307 +64 bytes
1: Decl: Ordinal5307
1: Mod: MFC42, base: 754e0000h
1: 25 Ordinal1184 +377 bytes
1: Decl: Ordinal1184
1: Mod: MFC42, base: 754e0000h
1: 26 _endthreadex +163 bytes
1: Decl: _endthreadex
1: Mod: msvcrt, base: 77b70000h
1: 27 GetModuleHandleA +223 bytes
1: Decl: GetModuleHandleA
1: Mod: kernel32, base: 7c800000h
Exception handler = WinApp::DispatchMsg()
Hi Shu Quan
This is call a crash. 😉
sv32 is still in the process list but it has crash definitly and HDS is still there because it has not receive instruction to shut itself down due to the crash.
Reading the execption it occur when you stop monitoring the network and the node force all its variable to NSCOM and somehow a pointer to one of the variable might be null or something.
But if you can no longer reproduce the crash I will be difficult for Jacques to do something...
Yes, It's a crash.
We failed to reproduce it on the site last weekend. But we still try to reproduce it.
Unfortunately, this morning, i also got another customer and said "PcVue's server main window disappered, but the event viewer is still there, and all the clients disconnected from the server." But when checked the logs, there is no crash log. 🙁


