more quick actions
minimize quick actions
General
2
Posts
2
Users
0
Likes
34
Views
Topic starter
Hi guys, I saw in 1 old topic answered by Nico here. It was mentioned that in the event that crash happen, below are steps to follow : 1. Try reproducing the issue on platform when it is possible 2. Create a SPR attaching the project AND the log files AND the dump files. 3. Make Hot case if the issue is blocking your customer But is there anything extra that we as support person can do? In some cases, for example with 1 client that we have in Korea, they have a lot of crash happen, but I would like to state they are using PcVue version 10. For this customer, normally it means I have to raise many SPR. Regardless, could there be any extra troubleshooting that technical support personnel might be able to do before pass over to developer? Thanks, Kantha
This topic was modified 2 years ago by LM
Posted : 19/07/2019 12:51 pm
Hello Kantha,
I'm not a developer and I speak about my experience, hoping that someone else more skilled will integrate or correct my statements.
This is what I usually do in case of PcVue crash events before raising an SPR or calling a developer:
- Try to exclude PcVue performance issue. A performance issue can be related to PcVue or HDS, and in this case you have to check: Handle, Thread and RAM Consumption of the two main executables (sv32.exe and HDS.exe). As an empyric rule, it can ring a bell in your head if sv32.exe RAM consumption is > 600MB for big projects and HDS.exe more than 100MB. Our colleague Raphael developed an useful tool - SvAppScan - that allows you to graph AUDIT performance files and see if there's an handle, thread or memory leak uncontrolled growth by displaying it's trend. Consider that sv32.exe - main PcVue executable - it's a 32 bit process, and it can allocate up to 4 GB of RAM (tanks to Large Address Aware). It will crash if it try to allocate more. Often performance issue cames from user programs (SCADA Basic, VBA, DLL, OCX, SvMgr etc.) that allocate system resources without freeing them (file or database management in SCADA-Basic, DLL in VBA... etc.).
- Try to exclude system performance issue: With Raphael tool (SvAppScan) you can diagnose how much RAM it's globally available in the system and how much PcVue is consuming. So you should exclude that an overcharged system disturbs PcVue to run smoothly. An underevaluated parameter is "Disk queue": you can have a well performing system (good CPU, good free RAM) but with a very slow storage (hard drive system - it happen especially in big virtualized environment that uses misconfigured external storage): This causes PcVue to go in internal timeout - in my experiences this can disturb especially client-server communication. You can check this parameter by using an open source tool called CrystalDiskMark that creates storage I/Os and monitoring Disk Queue using Windows Utility perfmon.exe. On an healty system, disk queue value should never overcome the value of "1".
- If you have several crashes, you can locate BinLogfilessv32crashexception.log files and check if the callstack (Sequence of functions that provokes the anomaly) it's more or less the same for all recorded crashes: it means that PcVue crashed always for the same reason.
On top of the list, if you are lucky, you can also see which is the involved PcVue module or function (usually PcVue functions starts with sv*, you can see there also Microsoft system calls). With a bit of experience, you can "decode" if crashes comes from a communication driver, OPC, HMI etc and have a direction to investigate and/or suggest a temporary workaround to your customer.
Hope it helps,
Filippo
Posted : 22/07/2019 5:23 pm