P.I. Engineering User Forum

Product Support, Technical Questions and Answers, and Examples for P.I. Engineering Products

You are not logged in.

#1 2017-04-23 16:28:42

nc
Member
Registered: 2017-04-23
Posts: 4

GUI (MacroWorks3g.exe) hanging; Suggestions?

Per the subject:

The MacroWorks3g.exe executable, when running, appears to ...

1. "max" out one of my logical processors
2. Hang for long periods of time - usually a minimum of 5 seconds

This behavior makes it especially difficult to do anything involving the GUI - especially recording macros for X-keys devices.

I'm new to the X-keys product line, so I would certainly appreciate any guidance that can be offered for diagnosing and solving this particular problem.

Offline

#2 2017-04-24 05:34:49

GordR
Member
Registered: 2017-04-05
Posts: 17

Re: GUI (MacroWorks3g.exe) hanging; Suggestions?

I had some hanging during MacroWorks script executions and found that adding delays between steps to allow the GUI to finish it's job solved that problem.  Especially anything that requires the GUI to display something new, like a setting change pop open or a pop up requester.

Offline

#3 2017-04-24 07:39:28

PIE Amber
Technical Software Developer
From: Williamston, MI
Registered: 2016-01-21
Posts: 196
Website

Re: GUI (MacroWorks3g.exe) hanging; Suggestions?

This is not something that happens for everyone, so we need to figure out why it would be happening for you. First thing, what version of Windows are you running? We'd also like to see your ErrorLog. You can find it by showing hidden files and folders in Windows. Then go to C:\Users\YOUR USERNAME\AppData\Local\PI Engineering\MacroWorks 3\ErrorLog.txt. Either upload it somewhere, or email it to tech@piengineering.com, or copy/paste here (if it's not too long).

I suspect it may be a permissions issue -- if your system is blocking a function due to settings or your antivirus software, it could explain it. The ErrorLog should be able to show me something in that case.

Also note we recommend running MW3.1 without other intense software running at the same time (except briefly, if you're doing app-specific programming). Try running it with nothing else running. Does it work better? It could simply be bogging down your computer combined with other software. Most likely it's the permissions thing above, but depending on your system it could be this too.


Amber from P.I. Engineering

Offline

#4 2017-04-24 07:53:07

nc
Member
Registered: 2017-04-23
Posts: 4

Re: GUI (MacroWorks3g.exe) hanging; Suggestions?

GordR,

I believe my issue might be separate from the one you mentioned; the Software Mode seems to work well enough (thus far) if MacroWorks3r.exe (the "system tray" app) IS running and MacroWorks3g.exe (the "full window" application) ISN'T running.  That is, concurrent execution of macros with the GUI running (for which the suggested in-macro delays might be appropriate) isn't necessarily my current goal, though I might look into that later.  I think I should have been a little clearer about the nature of my problem, so my apologies for that.

I'll be looking into PIE Amber's suggestions shortly.  I'll keep as much as possible "in-forum" for other users who might have this same problem.

Offline

#5 2017-04-24 08:14:14

nc
Member
Registered: 2017-04-23
Posts: 4

Re: GUI (MacroWorks3g.exe) hanging; Suggestions?

Amber,

I'll send my log to tech@piengineering.com shortly with a subject that will be similar to the thread title. Here is some of my system information via msinfo32:

OS Name    Microsoft Windows 10 Pro
Version    10.0.15063 Build 15063 <-- (Note: this is a post Windows 10 "Creator's Update" build, but I noticed the GUI problem "during" the "Anniversary Update" build as well)
Other OS Description     Not Available
OS Manufacturer    Microsoft Corporation
System Name    <redacted>
System Manufacturer    LENOVO
System Model    20BXCTO1WW
System Type    x64-based PC
System SKU    LENOVO_MT_20BX_BU_Think_FM_ThinkPad T450s
Processor    Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2594 Mhz, 2 Core(s), 4 Logical Processor(s)

Offline

#6 2017-04-24 11:09:16

PIE Amber
Technical Software Developer
From: Williamston, MI
Registered: 2016-01-21
Posts: 196
Website

Re: GUI (MacroWorks3g.exe) hanging; Suggestions?

Thank you for sending over that error log. I saw many instances of the same error, below. While I am not 100%, this would be consistent with a permissions issue (if Windows or another program is blocking access to a file, for example part of .NET).

Source       : System
Method      : StartWithShellExecuteEx
Date          : 2017-04-21
Time          : 17:58:59
Error          : The system cannot find the file specified
MW3          : v.1.1.1.88
Handled     : True
Stack Trace : at System.Diagnostics.Process.StartWithShellExecuteEx(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start()
   at System.Diagnostics.Process.Start(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start(String fileName, String arguments)
   at MW3r.FormMain.RunApp(String runPath, String argument)
Message : The system cannot find the file specified


1) Are you an administrator on this computer? If not, try running it under an administrator account.

2) Please try running MacroWorks 3.1 "as administrator" itself. You will need to shut it down completely to do so, exit out via the system tray icon or shut down via Task Manager, then right click, run as administrator. Does it work better?

I hope that helps. Please let me know how it goes.


Amber from P.I. Engineering

Offline

#7 2017-04-24 15:09:25

nc
Member
Registered: 2017-04-23
Posts: 4

Re: GUI (MacroWorks3g.exe) hanging; Suggestions?

Amber,

Running the application using administrative privileges does not appear to significantly improve the behavior of the GUI. I have not noticed further error log entries in the log file when observing the problem we are tracking.  I suspect the instances of the error you saw were from me doing testing with creating a shortcut that runs a Powershell command.  I witnessed our current GUI behavior before I was doing that testing.

For the rest of this thread, I'll be using the following substitutions:
r.exe = MacroWorks3r.exe
g.exe = MacroWorks3g.exe

I have both a XK-24 as well as a XK-68 Jog and Shuttle; I have witnessed the same behavior with both, but the following notes will be related specifically to the XK-68.

The following things were noticed when...
  a. r.exe was executed as an administrator
  b. a X-keys device is selected (XK-68 Jog and Shuttle) from device selection GUI of r.exe. 

1. The used memory doesn't appear to be growing in a significant way, so it doesn't appear to be related to some kind of memory leak of g.exe.

2. The software GUI (g.exe) will max out the processor when switching applications. This includes switching from another application to the g.exe window; the GUI becomes unresponsive in each case.

3.  r.exe appears to handle application switching and Software Mode macros well enough when g.exe isn't running.  If g.exe is "working" on something, the associated X-keys device begins to hang as well.  Not sure if this is just a side effect of g.exe churning on the the same processor used by r.exe.

4. There are two "maxed-out CPU" states for g.exe; both states generally appear to be triggered when switching the application focus (say, moving from g.exe to Google Chrome, Notepad to Windows Explorer, etc.).  Both states prevent operation of the GUI.
  State 1, "Brief": The CPU maxes out for several seconds, then returns to normal operation.
  State 2, "Prolonged": The CPU maxes out for far beyond the normal period of time; best to simply kill the g.exe process at this point.

State 2 may just be a variant of State 1 where g.exe is "permanently" churning on the CPU. Rather, it is possible that State 2 is just a very, very, very long duration version of State 1.

4. I can fairly reliably trigger State 1.  I haven't found a way to consistently trigger State 2.

5. The "resting" stack, or when g.exe isn't selected and isn't churning on an application focus change, looks like this:

ntoskrnl.exe!KeSynchronizeExecution+0x3f46
ntoskrnl.exe!KeWaitForMutexObject+0xfda
ntoskrnl.exe!KeWaitForMutexObject+0x9a1
ntoskrnl.exe!KeWaitForMutexObject+0x2b8
ntoskrnl.exe!KeCheckProcessorGroupAffinity+0xb64
ntoskrnl.exe!KeWaitForMutexObject+0x2a3e
ntoskrnl.exe!KeWaitForMutexObject+0x11a7
ntoskrnl.exe!KeWaitForMutexObject+0x9a1
ntoskrnl.exe!KeWaitForMutexObject+0x2b8
win32kfull.sys!HasHidTable+0x20f8
win32kfull.sys!HasHidTable+0x1d73
win32kfull.sys!NtUserWaitMessage+0x42
ntoskrnl.exe!_setjmpex+0x3b73
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x544
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x503
wow64.dll!Wow64KiUserCallbackDispatcher+0x3930
wow64.dll!Wow64LdrpInitialize+0x120
ntdll.dll!RtlCreateHashTableEx+0x2375
ntdll.dll!memset+0x1e3bc
ntdll.dll!LdrInitializeThunk+0x5b
ntdll.dll!LdrInitializeThunk+0xe

6. When g.exe is stuck in State 2, it looks like it is looping around some function calls.  Unfortunately, my Windows debugging knowledge is fairly limited; I don't know how to track statistics of function calls (quantity, duration/cpu time, etc.) in Windbg.  The best I have thus far is refreshing a text copy of the stack for the primary thread for g.exe and looking for functions that might stand out.

Offline

#8 2017-04-24 15:58:33

PIE Amber
Technical Software Developer
From: Williamston, MI
Registered: 2016-01-21
Posts: 196
Website

Re: GUI (MacroWorks3g.exe) hanging; Suggestions?

2. The software GUI (g.exe) will max out the processor when switching applications. This includes switching from another application to the g.exe window; the GUI becomes unresponsive in each case.

Switching windows causes MacroWorks to do something (we monitor which programs are in focus at all times for the application sensitive programming), so that may be a clue to where the problem lies. It definitely doesn't happen on all machines, but we haven't tested thoroughly with the latest Windows 10 update. It sounds like we definitely need to.

It sounds like your workflow involves a lot of window switching, which isn't necessarily that common. You should, of course, be able to switch windows, but it could explain why we haven't heard of this issue until now. As we look through at the issue, for a crude workaround, I recommend refraining from switching windows while using the GUI. I know this isn't ideal, but I am hopeful you can still program that way, and I want to eliminate the possibility that the window switching may be incidental (see if hangs may also eventually happen with that factor removed).

[Not your main issue, but just a note: Macros on the device are not intended to work when the GUI is open. Pressing a button with the GUI open makes it try to open the button for programming. Always test execution of buttons with the GUI closed.]


Amber from P.I. Engineering

Offline

Board footer

Powered by FluxBB