Aloha 5.3 EOD Grind Failing

[BIGGBYNinja]

I have an issue that just started happening at one of our stores and am having difficulty tracking down the culprit. Long-time reader and hoping somebody would be able to help, I would greatly appreciate it. Thanks for reading.

The BOH fileserver is XP Pro SP3 and it has Aloha Quickservice 5.3 installed in the D:\Aloha directory. Our end of day is set to run at 2 AM and the last few nights the grindq.exe process has failed on the BOH. Sometimes this leads to the FOH terminal saying "Waiting for (previous date) to grind..."

The behavior on the BOH is a title-less window (can just barely see the blue title bar, but nothing else) obscuring the screen contents, and is always on top of any other windows. There are two processes in task manager that must be ended to get rid of the window: grindq.exe and dwwin.exe

If I do not stop the ctlsvr service before killing these processes, they will start back up again and lead to the broken application window again.

Fortunately (and mysteriously) , the grindq process does actually work correctly if I run it manually. So the past few days fixing the issue has been performing the following:

1. Stop ctlsvr process
2. Kill grindq.exe and dwwin.exe processes
3. Run grindq /date 20110110
4. Start ctlsvr

This only takes a few minutes and always gets us up and running, but I am still lost as to why the grindq is breaking every night. I have tried viewing all of the TMP logs and searching online with no success.

I have uploaded my entire TMP folder here:

http://www.mediafire.com/?c2jxcyvdsjgllkb

The logs aren't helping me, but maybe I missed something. The closest I saw that pertained to the issue was the DEBOUT.SVR

Jan 07, 06:36:37 CTLSVR: Beginning broadcast thread...
Jan 07, 06:36:47 CTLSVR: WINHOOK started C:\WINDOWS\system32\cmd.exe /C D:\Aloha\bin\ecomhook.bat 20110106
Jan 08, 02:00:01 Renamed UPDATE.STR To UPDATE.HLD
Jan 08, 02:00:09 CTLSVR: Detected End Of Day in progress...
Jan 08, 02:00:29 1 - The Command args going to GrindExe = D:\Aloha\BIN\GRINDQ /NOMUTEX /DATE 20110107 /HWND 0 /IBERDIR D:\Aloha /EOD
Jan 08, 02:00:29 CTLSVR: Executing GRINDQ...
Jan 08, 02:00:29 waiting 1...
Jan 08, 07:00:14
Jan 08, 07:00:14 ............................................................
Jan 08, 07:00:14 CTLSVR: Started CtlServiceThread... version 5.3.47.633

That "waiting 1..." would be the last output before I restart the ctlsvr service.

Does anybody have any advice? Thanks again for taking the time to read and any suggestions.

 

[coorsman]

I saw mostly e-frequency errors on you trans.log grindq debout.g01.

:57:23 [2432] ProcessTXNGenericTextBufferTypeInfo() check has no e-frequency info
Jan 10, 03:57:23 [2432] ProcessTXNGenericTextBufferTypeInfo() check has no e-frequency info
Jan 10, 03:57:23 [2432] ProcessTXNGenericTextBufferTypeInfo() check has no e-frequency info
Jan 10, 03:57:23 [2432] ProcessTXNGenericTextBufferTypeInfo() check has no e-frequency info
Jan 10, 03:57:23 [2432] ProcessTXNGenericTextBufferTypeInfo() check has no e-frequency info
Jan 10, 03:57:23 [2432] ProcessTXNGenericTextBufferTypeInfo() check has no e-frequency info

Is your e-frequency running ok?


Cheers,
Coorsman

 

[BIGGBYNinja]

Thank you coorsman. I had my co-worker look into this issue as well and I believe he may have solved it. Here are his notes, in case somebody else comes across the same problem.

"I logged in and found the following entry in the event viewer:

Event Type: Error
Event Source: Application Error
Event Category: None
Event ID: 1000
Date: 1/11/2011
Time: 3:33:58 AM
User: N/A
Computer: ALOHABOH
Description:
Faulting application grindq.exe, version 5.3.47.0, faulting module msvcrt.dll, version 7.0.2600.5512, fault address 0x00036fa3.
For more information, see Help and Support Center at

http://go.microsoft.com/fwlink/events.asp.

Data:
0000: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 46 61 69 6c ion Fail
0010: 75 72 65 20 20 67 72 69 ure gri
0018: 6e 64 71 2e 65 78 65 20 ndq.exe
0020: 35 2e 33 2e 34 37 2e 30 5.3.47.0
0028: 20 69 6e 20 6d 73 76 63 in msvc
0030: 72 74 2e 64 6c 6c 20 37 rt.dll 7
0038: 2e 30 2e 32 36 30 30 2e .0.2600.
0040: 35 35 31 32 20 61 74 20 5512 at
0048: 6f 66 66 73 65 74 20 30 offset 0
0050: 30 30 33 36 66 61 33 0d 0036fa3.
0058: 0a .

Google search results pointed me towards reinstalling .net framework 1.1, but this did not fix the issue.

I played with security and permissions and ran a registry cleaner and sfc /scannow, none of which fixed it.

I looked at the aloha services and noticed they were running under the alohasvr user account. This is normally fine, but I changed it to Local System Account. I restarted the services and the grind finally ran correctly."

So in our case the solution was to simply change the ctlsvr, edcsvr, and other Aloha services to run under a different user account. I have no idea how this all started happening out of the blue, since this store has had these same settings and that same alohasvr user account for years. I think he might have figured it out though, and I will update this thread if we find anything else. Thanks coorsman for the reply.

 

[mmantion]

FYI, CTLSVR scans all dates subs in the aloha(qs) folder for the marker file GNDDBF30.XXX. if that is missing it grinds the folder.

So instead of stopping ctlsvr, you can just create the file GNDDBF30.XXX and CTLSVR will continue on to the Winhook (or ecomhook).

Then you can grind that dated sub at your leasure. Sometimes manual grinding doesn't work and a Grind /fixlog is required.