Hey everyone!

I'm having a weird error when debugging the TwitchNotifiy utility that Martins (mmozieko) wrote and I'm very curious as to what triggers it.

The error is as follows:

onecoreuap\base\diagnosis\platform\notifications\developer\util.cpp(174)\wpnapps.dll!00007FFBBFC64E8C: (caller: 00007FFBBFC64B35) ReturnHr(1) tid(3168) 80070490 Element not found.
onecoreuap\base\diagnosis\platform\notifications\developer\basenotification.cpp(36)\wpnapps.dll!00007FFBBFC64B52: (caller: 00007FFBBFC6123E) LogHr(1) tid(3168) 80070490 Element not found.

The error appears after either one of the following functions was called:

WindowsToast_Create()
WindowsToast_ShowSimple()

Now, in the beginning, that error didn't affect anything. The notifications were still being displayed regardless. However, whenever I try adding something to the program like a message box, the notifications start flooding my action center as soon as I interact with it.

I'd also like to emphasize that this undefined behavior only occurs on Windows 11. On Windows 10 everything runs smoothly.

Is there anything special I need to add to the source code in order to be complaint with Windows 11 as well?

Those exceptions are probably a normal thing and you can completely ignore them. Nowadays Windows internally is implemented with C++ that uses C++ exceptions. But they always are catching exceptions with try/except and handling themselves internally.

I am running TwitchNotify on Windows 11 and it works fine for me.

What exactly are you changing for the problem to happen? I could try doing the same thing on my Windows.

You saying that those exceptions are normal behavior was the conformation I needed!

I was so caught up in those exceptions that I completely overlooked a bug that was lurking elsewhere and caused this undefined behavior.

Basically, I had a bunch of strings that represented dates that I needed to sort and the way I chose to do it was to convert them to SYSTEMTIME, then to FILETIME and then call the CompareFileTime() function that compared them and allowed me to position every date in its correct place.

Everything was working fine in debug mode but when the time has finally come to switch to release mode, everything fell apart. Turned out it was because I didn't initialize the SYSTEMTIME and FILETIME structs to 0...

Which leads me to the following questions:

1. Aside from the obvious difference in executable size, what other differences are there between debug and release modes?
2. If a bug appears in release mode but not in debug mode, what would be an effective way to debug it if release mode doesn't contain any debug information for me to work with?

The problem most likely is that variables in debug mode contain different values on stack from release mode. Because of different code that is generated due to enabled optimizations. The values you had in debug mode did not trigger the problem, but in release build they were bad enough.

You can debug release builds just fine. Debug info is a separate setting from optimization setting. You can enable -Zi and you'll have .pdb file. Sometimes it will be a bit harder to debug, because some variables have "disappeared" or line info is very reliable because optimizations rearranged code. But otherwise same kind of debugging will work.

For uninitialized reads MSVC offers -RTCu argument that will catch places that use uninitialized variables at runtime.

I finally got it. Thanks a lot <3

By the way, how important is it to clean up resources associated with my window?

If I have say, an icon, a WinHTTP session and a thread, do I need to call the following functions when I process the WM_DESTROY message:

Shell_NotifyIcon(NIM_DELETE, &nid);
WinHttpCloseHandle(hSession);
CloseHandle(hThread);

Or can I count on the OS to clean up everything for me so that I won't have to waste any of the user time on waiting while my program finishes terminating everything in the background?

You don't need to release any OS resources, like window hwnd's, or handles, or memory. OS cleans up everything after your process has died.

But you need Shell_NotifyIcon with NIM_DELETE to remove icon from systray, because Explorer keeps icon even if process has died - it expects application to explicitly ask when to remove icon.