2

Our program hangs in the customer's machine (mostly in Windows 7).

The program is a client that connects to our server in a different machine. It is a C program with Win32 programming graphical interface.

Symptom: While executing our client application at random, it suddenly turns whitish and the dialog box "Application has stopped responding" appears, with two options: "close the application", "wait for the application to respond" etc. The customer computer says AppHang-B1.

We were not able to reproduce this problem in our systems. But once I reproduced the issue and took a crash dump.

The call stack says the following.

0012fa20 76accde0 76ac18d9 0012fcb0 00000000 ntdll!KiFastSystemCallRet
0012fa24 76ac18d9 0012fcb0 00000000 00000000 user32!NtUserGetMessage+0xc
0012fa48 00442dfc 0012fcb0 00000000 00000000 user32!GetMessageA+0x8d
0012fef8 00469b87 00400000 00000000 0334efed OurApp32!WinMain+0x12ec     [e:\mswnt\api55a\OurAppFolder\term\wbtmain.c @ 1350]
0012ff88 7589ee1c 7ffde000 0012ffd4 774237eb OurApp32!__tmainCRTStartup+0x113 [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c @ 263]
0012ff94 774237eb 7ffde000 7eb0a7fe 00000000 kernel32!BaseThreadInitThunk+0xe
0012ffd4 774237be 00469bf2 7ffde000 00000000 ntdll!__RtlUserThreadStart+0x70
0012ffec 00000000 00469bf2 7ffde000 00000000 ntdll!_RtlUserThreadStart+0x1b

Source code at the crash below. Note that it hangs at the GetMessage line.

  /* Handle messages - until were done */
  while (GetMessage(&msg,NULL,0,0)) { /* CRASH POINTS HERE */
     MenuWindow =  GetAccelerators(&msg);
     if (!TranslateAccelerator(MenuWindow.hWnd, MenuWindow.WinAccel, &msg)) {
        if ((MenuWindow.hWnd != 0 && MenuWindow.hWnd != hMainWnd) ||
           !TransmitFromMain(&msg)) { /* Screen to avoid key translation )*/
              TranslateMessage(&msg);    /* Translates virtual key codes    */
              DispatchMessage(&msg);     /* Dispatches message to window    */
        }
     }
  }

Local variables from windbg

hInstance   0x00400000 struct HINSTANCE__ * 0012ff00
hPrevInstance   0x00000000 struct HINSTANCE__ * 0012ff04
lpCmdLine   0x0334efed "-dMapper.msf"   0012ff08
nCmdShowz   0n1 0012ff0c
Alertmsg    char [256] ""   0012fdf0
bstatus 0n1 0012fef4
hData   0x045b29c8  0012fbac
hTDC    0xc6013534 struct HDC__ *   0012fccc
   i    0n39    0012fdec
lpCtrlData  0x045b29c8 struct ctrldata *    0012fba8
msg struct tagMSG   0012fcb0
 hwnd   0x001e0fe4 struct HWND__ *  0012fcb0
 message    0x325   0012fcb4
 wParam 0   0012fcb8
 lParam 0n0 0012fcbc
 time   0x9ee0b98   0012fcc0
 pt struct tagPOINT 0012fcc4
MsgHdr  char [256] ""   0012fcd0
scm struct CHARMETRIC   0012fdd4
sectionname char [256] "MPC"    0012fbb0

Any ideas why is it hanging? I was not able to get any information on msg->message 0x325

Thanks in advance


Some more information and answers to the questions below

Thanks for the replies Yes I have to change the GetMessage loop into something like

 while ( (ret = GetMessage(&msg,NULL,0,0) != 0 ) {
      if (ret == -1)
      {

I will be doing that

@Lundin Its not a multi threaded application.

Some more info on the Hang ... the Hang happens mostly when we Alt Tab from other applications into our Client. although it may happen at any time ... Any insight on what the msg 0x325 might be ?

  • I don't know if that actually affects your application, but it's not recommended to write `while (GetMessage(...)) {` since `GetMessage` will return `-1` in case of an error. – Michael May 19 '14 at 09:26
  • @Michael Non-zero evaluates to Boolean true in C, so I don't see how that would be a problem. – Lundin May 19 '14 at 09:42
  • Is this a multi-threaded app? Since the 2nd parameter to GetMessage is NULL, you don't specify which HWND that you are interested in. So you get messages from all windows in the application. And after that, you seem to assume that the message came from a specific HWND. What happens if you switch out NULL for the correct HWND? – Lundin May 19 '14 at 09:45
  • More likely though, the problem is in your Wndproc. For example, maybe there is a case when you aren't returning 0 after some WM event that your application handles. – Lundin May 19 '14 at 09:47
  • 1
    `GetMessage()` is the usual place where a Win32 application will rest when it does nothing to do (well, that and `WaitMessage()`), so there is nothing weird in that. The `msg` struct is an output parameter from that function, and in the stack trace it may be uninitialized, so is not worth looking at. Maybe your hang is from another thread? – rodrigo May 19 '14 at 09:50
  • 3
    @Lundin: The fact that -1 evaluates to `true` means that the body of the loop would go on to process the message as if no error had occurred. That may not be such a good idea. – Michael May 19 '14 at 10:16
  • by not splitting the communication and the gui and depending on what protocol you are using you may get into trouble. it normally is a better design to let the gui run in its own (main) thread and let any work be done in another, then you will not get the unresponsive message which happens when an app is not reading its window messages due to that it is busy waiting for something (like communication) – AndersK May 19 '14 at 11:02
  • After typing "win32 message 0x325" in Google I found [this link](http://msdn.microsoft.com/en-us/library/windows/desktop/ms681388%28v=vs.85%29.aspx). According to it, message 0x325 is `ERROR_INVALID_ACE_CONDITION` which indicates that *The specified access control entry (ACE) contains an invalid condition.* Does this help somehow? – AlwaysLearningNewStuff May 19 '14 at 11:51
  • GUI and connecting to another machine, can this even work reliably? The "Application is not responding" thingie normally pops up when GetMessage hasn't been called for 2 or so seconds. Which, for making a network connection, is a quite shitty case, but entirely possible. My guess is that your customer simply needs more than those two seconds to connect, and boom. – Damon May 19 '14 at 13:42

0 Answers0