SELECT i1.Id, Collect() as messages
INTO output
FROM input 
group by i1.id, SessionWindow(second, 10, 15)

SELECT i1.Id, i1.EventEnqueuedUtcTime as t
into output
FROM Input as i1 TIMESTAMP BY EventEnqueuedUtcTime
LEFT outer JOIN Input as i2 TIMESTAMP BY EventEnqueuedUtcTime
ON i1.Id = i2.Id 
AND DATEDIFF(second,i1,i2) BETWEEN 0 AND 15
and i2.EventEnqueuedUtcTime > i1.EventEnqueuedUtcTime
WHERE i2 IS NULL

error APPX3210: App manifest references the image 'Assets\Logo.png' which does not have a candidate in main app package.

The manifest referenced Logo.png indeed. But the file in the package was logo.scale-100.png. When I renamed logo.scale-100.png to logo.png (what the manifest asked for), the manifest errored out with a red cross. When I then used the manifest editor to point to logo.png, Visual Studio renamed it to logo.scale-100.png. So back to square 1: build the store package and error happens.

Sooo. It appears that the default scale has changed to 200%. OK. Fine. And? Why does that matter?

It matters because the main app package contains resources for whatever the default scale is. And for UWP, the default is 200. Since I use app bundles, my Logo-100.png ended up in a satellite app package, and the main package does not have any logo (since I didn't provide the default 200). Hence, my app would not be installable on a system that requires scale-200.

When I renamed the file to Logo.png, the editor complained because it assumed that images without qualifiers were in the default scale (200), and my logo didn't have the correct dimensions for that scale.

There is an explanation for this in the porting doc, but it is a little buried:

"The default asset scale for Universal Windows apps is 200. If your project includes assets not scaled at 200, you will need to add a <UapDefaultAssetScale> element with the value of the scale of your assets to this PropertyGroup. Learn more about assets and scales."

[Thanks to Srdjan Jovcic for his explanation.]

When the system is in tablet mode, a back button appears on the left in the task bar. However, if the app is in PC mode, the app might need to have its own back button. You might not want both. This means that your app:

1.      Needs to detect whether it is in tablet or pc-mode

2.      If in tablet mode, don't show a back button since the system already has one in the taskbar

3.      If in PC mode, show the back button (if there is something on the back stack.)

In order to detect 1) you should use this:

UIViewSettings.GetForCurrentView().UserInteractionMode == UserInteractionMode.Mouse;//or Touch

Mouse indicates PC mode; Touch indicates tablet mode. Depending on the outcome, you can hide or show your app's back button in the title bar by setting AppViewBackButtonVisibility to Visible or Collapsed.

You then need to handle one event for both

SystemNavigationManager.GetForCurrentView().BackRequested

And don't forget to set BackRequestedEventArgs.Handled to true if you're handling the back navigation. Otherwise the system will also navigate away from your app.

Complete code:

protected override void OnNavigatedTo(NavigationEventArgs e)

{

    SystemNavigationManager.GetForCurrentView().AppViewBackButtonVisibility =

        (UIViewSettings.GetForCurrentView().UserInteractionMode == UserInteractionMode.Mouse) ?

        AppViewBackButtonVisibility.Visible : AppViewBackButtonVisibility.Collapsed;

    SystemNavigationManager.GetForCurrentView().BackRequested += SettingsPage_BackRequested;

}

protected override void OnNavigatingFrom(NavigatingCancelEventArgs e)

{

    SystemNavigationManager.GetForCurrentView().BackRequested -= SettingsPage_BackRequested;

}

private void SettingsPage_BackRequested(object sender, BackRequestedEventArgs e)

{

    App.RootFrame.Navigate(typeof(MainPage));

    e.Handled = true;

}

When you want to use Win32 or COM APIs in your Windows Store app, there is a subset of APIs you can use. Microsoft recently asked what Win32 API or functionality you as developers are missing from the list. I think this is a great initiative to expand the reach and capabilities of WinRT apps. This has obviously tickled your interest as well. Finally you can seriously look at that old VB6 app that uses some utility C DLLs you couldn’t justify porting to WinRT. And with universal apps, you might even be able to turn it into a Windows Phone app as well.

So here is your chance to let us know what you need. Problem is, you’re not quite sure what that is. You want to find out what APIs you’re actually using in those old C/C++ DLLs you haven't touched in a while.

You have several options here. You can add the WINAPI_FAMILY=WINAPI_PARTITION_APP preprocessor flag and try to build your binaries. Alternatively, you can build a new Windows Store app, link the DLLs in, and test your app with Windows Application Certification Tool (WACK). It turns out there is an even easier way to find those offending APIs. Here’s how to go about it.

1. Create a Windows Store app from a template. Any template is fine.
2. Don’t do anything to the app itself. Hit F5 to deploy your app. Just make sure you build the release app, otherwise you'll get false positives for APIs that are only found in debug builds. 
3. Now here’s the trick. You'll want to drop your legacy DLLs into this location: \myapp\bin\Release\AppX\. This will be a folder where you find myapp.exe and the AppxManifest.xml
4. Start WACK  and select your app.
5. Run through WACK and it will flag all the APIs you’re using that are not on the "approved" Win32 and COM API list.

Note that you'll get a lot of errors if you have an older version of the CRT that is not compatible with Windows RT.

In the VM settings it says "Serial Port 2" which was somewhat weird already. Also in Device Manager on the VM it mentioned that the COM1 was already in use. Then I hit this article. Now I don't read Portuguese but the pictures are quite self-explanatory. Apparently when you have a printer connected to your machine, the first port is used by your printer. Adjusting the bcdedit settings fixed the problem.

xperf: error: NT Kernel Logger: Cannot create a file when that file already exists. (0xb7).

Weird because I ran the same command successfully multiple times before. Trying to stop a potentially conflicting session by using:

Xperf –d blah.etl

Failed with this error:

xperf: error: Merge ETL: The specified path is invalid. (0xa1).

And the event log contained this:

Session "NT Kernel Logger" failed to start with the following error: 0xC0000035

What has changed was that I had started ProcMon.exe. That uses the NT Kernel Logger. Exiting that process cleared the way for my first command.

The AMD64 Architecture Programmer's Manual (Volume 2: System Programming) mentions this:

No Execute (NX) Bit. Bit 63. This bit is present in the translation-table entries defined for PAE paging, with the exception that the legacy-mode PDPE does not contain this bit. This bit is not supported by non-PAE paging.

Again from Windows Internals we know that PTEs with PAE enabled are 64 bits long; without PAE they are only 32 bits long. There simply is no bit 63 for non-PAE paging. We can see it in the debugger.

Here is a call stack from the non-PAE crash dump:

0: kd> k

ChildEBP RetAddr

8292dc0c 968a1160 nt!KeBugCheckEx+0x1e

8292dc3c 968a1768 i8042prt!I8xProcessCrashDump+0x251

8292dc88 82840d4d i8042prt!I8042KeyboardInterruptService+0x2ce

8292dc88 8286449a nt!KiInterruptDispatch+0x6d

8292dd24 00000000 nt!KiIdleLoop+0x1a

If we dump out the the ChildEBP for the 2^nd frame:

0: kd> !pte 8292dc3c

VA 8292dc3c

PDE at C0300828 PTE at C020A4B4

contains 001BF063 contains 0292D963

pfn 1bf ---DA--KWEV pfn 292d -G-DA—KWEV

You see that the PTE contains a 32 bit value (0292D963).

The same exercise on a PAE enabled system gives us this call stack:

1: kd> k

ChildEBP RetAddr

807e1c0c 928bd160 nt!KeBugCheckEx+0x1e

807e1c3c 928bd768 i8042prt!I8xProcessCrashDump+0x251

807e1c88 828587cd i8042prt!I8042KeyboardInterruptService+0x2ce

807e1c88 8288101a nt!KiInterruptDispatch+0x6d

807e1d24 00000000 nt!KiIdleLoop+0x1a

The PTE here is 64 bit:

1: kd> !pte 807e1c3c

VA 807e1c3c

PDE at C0602018 PTE at C0403F08

contains 000000007A986863 contains 800000002D21F963

pfn 7a986 ---DA--KWEV pfn 2d21f -G-DA--KW-V

We would expect bit 63 on the ChildEBP to be set (EBP is on the stack and we would not want to execute any code from the stack: NX should be 1).

1: kd> .formats 800000002D21F963

Evaluate expression:

Hex: 80000000`2d21f963

Decimal: -9223372036097574557

Octal: 1000000000005510374543

Binary: 10000000 00000000 00000000 00000000 00101101 00100001 11111001 01100011

…

How about the return address of that same frame?

1: kd> !pte 928bd768

VA 928bd768

PDE at C06024A0 PTE at C04945E8

contains 0000000023615863 contains 000000007B9CD121

pfn 23615 ---DA--KWEV pfn 7b9cd -G--A—KREV

There the bit is not set:

1: kd> .formats 000000007B9CD121

Evaluate expression:

Hex: 7b9cd121

Decimal: 2073874721

Octal: 17347150441

Binary: 01111011 10011100 11010001 00100001

…

Note that .formats truncates the preceding 0s.

So I ask my friend Pat. He mentioned Reliability Monitor. So I type Windows key, "reliability", I select "View Reliability History" and I got this:

The nice thing is that it gives you a full history what went wrong, but also what is installed and when on the machine. You can even export an xml file and send it over or ask for it. This might come in handy when your mon/dad/aunt/neighbor claims that her/his machine magically became very sluggish without any user interaction.

Instead of PoolMon you can also use WPT and X-Perf. Once installed, you run it like so:

xperf -on diageasy+pool -stackwalk PoolAlloc

Then you repro the leak. Once done you stop the trace with this:

xperf -d leaker.etl.

When you then open the trace in XPerfView, you will see four pool graphs in the fly-out:

When you go to one of the graphs, you'll see a nice jagged line in there. Hovering the mouse over the graph will show the pool tag associated with the pool allocations.

But there is more. When you select the jagged line in the graph, right-click and get the summary table you can actuall get the call stack. You have to rearrange the columns a bit. Pooltag first, then call stack will be good. Throw the type column to the right. Of course you need to have symbols loaded. But here is what you'll get:

This is obviously a convoluted scenario with a large frequent leak from NotMyFault. Nevertheless, it is easy to get to the culprit. If you have symbols for myfault.sys available, then you would right there and then have the function and source line.