{"id":12743,"date":"2024-11-25T05:57:32","date_gmt":"2024-11-25T13:57:32","guid":{"rendered":"https:\/\/www.coretechnologies.com\/blog\/?p=12743"},"modified":"2024-11-25T05:57:32","modified_gmt":"2024-11-25T13:57:32","slug":"debugview-messages","status":"publish","type":"post","link":"https:\/\/www.coretechnologies.com\/blog\/alwaysup\/debugview-messages\/","title":{"rendered":"Q&A: With AlwaysUp, Where Do My Application’s Debug Messages Go?"},"content":{"rendered":"
\"With<\/div>\n
\n  We have installed AlwaysUp<\/a> in a number of our Windows servers, and it works great.<\/p>\n

We have a specific application that outputs debugging messages that are usually visible in the Windows Debug console view via the Sysinternals DebugView<\/a> or DebugView++<\/a> desktop applications. <\/p>\n

When we start the same application from AlwaysUp, I don’t see the debug messages in the DebugView console. Do you know where they go?<\/p>\n

— Giovanni<\/p>\n<\/div>\n

Hi Giovanni, thanks for getting in touch.<\/p>\n

We’ve seen this problem before. To explain in a sentence, you’re not seeing your applications debug messages because AlwaysUp is running your application in Session 0 while DebugView is monitoring your logon session. <\/p>\n

But that’s a mouthful! Let’s try to explain what it means. \ud83d\ude42<\/p>\n

Windows Sessions, in a nutshell<\/h2>\n

To understand what’s going on, it’s important to be aware of Windows sessions<\/a> and how they work. In case you could use a refresher on this very technical topic, here are a few facts about sessions:<\/p>\n

    \n
  1. \n

    When you log in to your computer, Windows creates a new session for you.<\/b> That session stays open until you log out — or Windows restarts. You can think of a session as the “container” for your entire login experience.<\/p>\n<\/li>\n

  2. \n

    A session holds your desktop and all the programs you launch.<\/b> Indeed, every application you start runs in your session.<\/p>\n<\/li>\n

  3. \n

    By design, Windows allows programs running in the same session to communicate freely. However, because of security restrictions, applications running in different sessions cannot easily interact<\/b>.<\/p>\n

    For example, an application running in your session cannot use the popular EnumWindows<\/a> API function to list the top-level windows in someone else’s session. Windows simply disallows that overreach.<\/p>\n<\/li>\n

  4. \n

    Sessions are numbered.<\/b> The first person to log in to the computer is given Session 1 (“the session with ID 1”). The next person to log in is assigned Session 2, and so on.<\/p>\n<\/li>\n

  5. \n

    When your computer boots, Windows automatically creates a special session, called Session 0<\/b>. All Windows Services — which may start at boot before anyone logs on — run in Session 0.<\/p>\n

    Session 0 is sometimes called the “console” or “background” session because of the special role it plays.<\/p>\n<\/li>\n<\/ol>\n

    And with that framework in place, let’s return to your specific situation.<\/p>\n

    DebugView and your application are running in different Windows sessions<\/h2>\n

    When you logged into your PC — either using the keyboard and mouse or remotely via RDP — Windows created a new session for you. Let’s say it’s Session 1 (but it could just as well be Session 2 or 3 if you weren’t the first person to log in after boot).<\/p>\n

    So when you start DebugView on your desktop, Windows launches it in Session 1. DebugView comes up visibly on your desktop, like any other application you start.<\/p>\n

    Similarly, when you start your application normally (without AlwaysUp), it will likely pop up on-screen as well. And DebugView will log its debugging messages, as expected.<\/p>\n

    But the situation is different when AlwaysUp runs your application. Instead of starting it visibly on your desktop, in Session 1, AlwaysUp starts your application in Session 0<\/b> — the session created at boot. Recall that’s where all Windows Services operate.<\/p>\n

    In that situation, DebugView will not capture messages from your application. That’s because DebugView is only monitoring applications running in Session 1 — the same session where it’s running.<\/p>\n

    The solution: Configure DebugView to capture messages from Session 0<\/h2>\n

    Fortunately there’s a simple fix:<\/p>\n

      \n
    1. \n

      Start DebugView.<\/p>\n<\/li>\n

    2. \n

      Select the Capture<\/b> menu and ensure that Capture Global Win32<\/b> is checked:<\/p>\n

      \"Capture<\/a><\/div>\n<\/li>\n<\/ol>\n

      With that option active, DebugView will capture messages from all Windows sessions — not only the session where it’s running.<\/p>\n

      The somewhat dated DebugView help file<\/a> explains what’s going on this way:<\/p>\n

       If you run DebugView in a remote logon session of Windows 2000 Terminal Services, DebugView adds a Capture Global Win32<\/b> menu item to the Capture<\/b> menu. Whereas the Capture Win32<\/b> menu item and associated toolbar button enable and disable capture of debug output in DebugView’s local logon session, the Capture Global Win32<\/b> menu item lets you enable and disable the capture of debug output that is generated in the console (global) session. Win32 services run in the console session, so this feature lets you capture the output that services generate even when you are running DebugView in another logon session.<\/p>\n<\/div>\n

      You can capture debug messages from all sessions with DebugView++ too<\/h2>\n

      DebugView++ provides a similar Capture Global Win32<\/b> option, which is on by default. It’s available under the Log<\/b> menu:<\/p>\n

      \"Capture<\/a><\/div>\n

      So you’re free to use either tool when running your application as a Windows Service with AlwaysUp.<\/p>\n

      \nHappy debugging!\n<\/p>\n

      \n
      \n\n\n\n
      More articles about AlwaysUp…<\/nobr><\/span><\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n