There is documentation out there (references at the end of this post), but i didn't find anything that went end to end without any gaps for an inexperienced Windows 8 developer like me to follow. I also noticed some of the content had changed a little since Windows 8 was released.

This post will show you how to implement basic background audio in a working (JavaScript based) sample for Windows 8.1.

Starting right at the beginning:

1. Open Visual Studio and select the options to create a new project, based on the JavaScript "Blank App" template. (The name, location etc. are up to you).

2. 'OK' the new application wizard and you should arrive at the basic new application screen with the default.js open and a list of resources listed under your solution on the right.

3. Add an .mp3 to the solution to test things out with. (For a real project you will want to build a file picker, but for this we can just add an .mp3 to the project).

You can do this by creating a 'audio' folder and adding the file to play in the new folder.

Right click on the Application name under solution explorer, then select "Add", "New Folder".

I called the new folder "audio" but it doesn't matter too much what you call it.

4. Right click on your new "audio" folder and choose "Add", "Existing Item". Then navigate to the audio file you want to use in the 'Add Item' dialog.

You should end up with a solution explorer that looks like this:

5. At this point, we could go right ahead and make a simple change that would allow us to play the track. Lets do that just to see some progress.

In Solution Explorer, go to default.html and double click it to open it in the main window. Then insert the following 3 lines of HTML 5 code:

<audio id="audiotag" controls="controls">
<source src="audio/b.mp3" />
</audio>

Default.html should look like this:

6. You should now have an app that plays audio. You should start the application to test this is true. (Click on the big green play button that says "local machine" at the top).

The application should look like this (and play the file you added):

The thing you will notice is that when you switch to another application or minimize the app, your audio stops playing. At this point, the app is not capable of background audio (try it).

To get the application ready for background audio, there are three high level steps:

a) A background audio declaration must be in the app manifest.

b) You must set the stream category (msAudioCategory) to either Communications or BackgroundCapableMedia.

c) Your app must register for media transport controls.

Expanding on each:

a) Declare background audio in the application manifest:

You can do this part graphically or in the xml. 

Double click on the package.appxmanifest file in the solution explorer window and it will open up the manifest settings in a nice UI:

In the editor choose the "Declarations" tab, then click the "Add" button:

You need to select "Audio" and type "default.html" in for the start page.

That's it for part a) we can close the package.appxmanifest file.

b) Set the stream category (msAudioCategory) to BackgroundCapableMedia

This part is a snap. Just jump back to the HTML in "default.html" and change the audio element to include this information.

The original 3 lines of HTML now looks like this:

<audio id="audiotag" controls="controls" msAudioCategory="BackgroundCapableMedia" >
<source src="audio/b.mp3" />
</audio>

In the editor:

(Don't worry that the msAudioCategory attribute has a squiggle under it for now)

c) Register for the media transport controls

Because you are playing background audio, you must register and handle the media controls.

What are they?

They are the buttons you get when you navigate away from your background audio playing application that let you handle volume and song selection:

Without this functionality in your app, the background audio wont work (but the audio will while the app has focus).

To get it done (the minimal amount) you need to add some code:

In solution explorer navigate to the "js" folder, then open the "default.js" file.

When it is first opened, it will look like this:

We need to add the following code (explanations are inline):

In app.onactivated we add:

//add the media control
var MediaControls = Windows.Media.MediaControl;

// Add event listeners for the buttons
MediaControls.addEventListener("playpressed", play, false);
MediaControls.addEventListener("pausepressed", pause, false);
MediaControls.addEventListener("playpausetogglepressed", playpausetoggle, false);

// Add event listeners for the audio element
document.getElementById("audiotag").addEventListener("playing", playing, false);
document.getElementById("audiotag").addEventListener("paused", paused, false);
document.getElementById("audiotag").addEventListener("ended", ended, false);

The result for app.onactivated will look like this (note the code is added just after the default code but before the closing brace):

Now all we need is handler functions for that media control. Again, a very basic example might look like this:

// Define functions that will be the event handlers
function play() {

}

function pause() {

}

function playpausetoggle() {

}

function playing() {

}

function paused() {

}

function ended() {

}

We paste the functions in just above the app.start(); code.

Note that none of the wiring is done. However, we should find that the application will now play the audio in the background.

As expected, the audio continues to play in the background when the app is minimized or another app is switched in. We also get the audio controls although they don't do anything.

(I've attached the very basic solution to this post - i removed the audio file so you just need to add an mp3 in the audio folder - call it b.mp3 to make it simple, or modify the code with your file name).

That's it. Seems straight forward to me now, but it took me longer than it should have, hence the blog post.

The appropriate resources are:

Being Productive When your App is Off-screen - Blog post.

Adding Audio to a Windows Application - MSDN.

Audio Sample Code - MSDN.

Background Media - Channel 9 Talk

Configure Media Controls - MSDN (shows you how to complete the controls)

Programming Windows Apps - Free eBook

Have a great weekend.

App3.zip

Unfortunately, the buckets can leak pretty quickly and retaining the content is what this post is all about. The buckets we should probably call capacitors. The array is an integrated circuit. This post is concerned with how we retain the "data" despite the energy constantly dissipating from the cell.  

It goes something like this:

During the active operation of a Windows device the contents of system memory (our buckets) are maintained through a process called “automatic refresh”. It also gets a zap when the DRAM is ‘touched’ through via a “normal” read or write.

(It is interesting to note that read operations from DRAM are destructive; during a read the charge is removed from the cell, and the sense amplifiers on the chip rewrite the cell in much the same way a write operation would occur ).

The amount of time between automatic refreshes is specific to the DRAM type but it is usually expressed in milliseconds. (As an example, automatic refresh is required at least every 64ms in the DDR2 specification ). 

The automatic refresh operation is responsible for a large portion of the total system power cost during active (screen on) device use.

During screen off, or standby, a different approach is taken although memory refresh can still be a significant part of the total standby power consumption.

Self-refresh, sometimes referred to as IDD6 is a DRAM power mode where the memory controller clock is deactivated to reduce the power consumption of the system.

During self-refresh the DRAM automatically executes a refresh operation using the internal DRAM refresh counter rather than relying on the memory controller clock to signal an automatic refresh.

In the context of a Windows system ‘standby’ is during sleep (S3) or Connected Standby. Both low power modes require the contents of system memory to be maintained. This is in contrast to ‘Hibernate’ (S4) mode where the contents of memory are saved to the hard disk and the DRAM turned off with the rest of the system. S4 has a considerable impact on the time taken to wake the device compared to sleep but an improvement in standby capacity because the DRAM refresh is disabled once the memory content is saved to disk.

In addition to the self-refresh mode there are a series of power management features defined in the DRAM specifications and implemented by some DRAM manufacturers to further reduce the power consumption of a device during standby.

Some of the advanced power features for memory are enabled and configured during DRAM or system manufacture, others may be exposed via system firmware and controlled and optimized by the operating system in partnership with the device manufacturer.

Partial Array Self Refresh (PASR) is one such feature. PASR allows portions of a memory array to be put into a no refresh state while the device is operating in standby.

Typically the entire memory array is put into self-refresh during standby because there is the hardware has no knowledge of memory content, no way to determine which pages are important to the system. The assumption must be that the entire DRAM array contains important data.

Using PASR the Operating System should intelligently place data during active use so that only a portion of the DRAM requires self-refresh during standby (because the OS has grouped memory pages in an efficient way).

In the example below memory pages are placed in bank 1 and bank 0 only, allowing self-refresh to be disabled on the other banks during standby.

In the LP-DDR3 JEDEC specification PASR uses two registers to control which memory banks, and which segments should be refreshed during standby.

- Mode Register 16 (MR16), the bank mask
- Mode Register 17 (MR17), the segment mask

DRAM modules that support PASR are divided into Banks and Segments.

A DRAM module typically contains 8 banks and each bank is broken into 8 segments.

The PASR registers MR16, and MR17 contain 8 bits each. The 8 bits in each register line up with the 8 banks, and 8 segments of those banks. In this way, the register provides a mask of the banks requiring self-refresh and which do not. The registers can be manipulated by the memory controller to control which banks should be refreshed at a given time.

It is important to note that there is not an individual register for each bank. This would mean that the granularity offered by this bitmask is not individual segments on individual banks, but rather – the same segments on every bank if the segment mask (MR17) is in use.

Another interesting point is that in the specification, the PASR mode registers are documented as write only. There is no interface to determine the current value of the registers; only to write the value. So the system would need to maintain knowledge of the banks currently being self refreshed.

It sounds really interesting. I should mention, I don't actually know of a system that is actively using PASR yet. That's not to say they don't exist, i just haven't found one. I will add a reference to this post if/when i do.  

Before i sign off, there is another self-refresh feature called Temperature Controlled Self Refresh (TCSR) worth a quick introduction:

TCSR is based on the idea is that the electrical charge in DRAM dissipates at a lower rate when a device is cool. So, as the device cools down during sleep we wont need to charge the DRAM cells as frequently. So, in the (LP-DDR) specifications for DRAM there is a feature (TCSR) which is able to detect when the device has cooled down to actively reduce the self-refresh frequency. This give us longer battery life. Neat.

The real point of this post - references for DRAM refresh: 

JEDEC DDR3 Specification
https://www.jedec.org/standards-documents/docs/jesd-79-3d

JEDEC DDR2 Specification
https://www.jedec.org/standards-documents/docs/jesd-79-2e

JEDEC LP-DDR3 Specification
https://www.jedec.org/sites/default/files/docs/JESD209-3.pdf 

JEDEC LP-DDR2 Specification
https://www.jedec.org/sites/default/files/docs/JESD209-2B.pdf

Temperature Controlled Self Refresh: Micron
https://www.elpida.com/pdfs/E0599E20.pdf

PASR Reference: Micron
https://www.elpida.com/pdfs/E0597E10.pdf

Deep Power Down Whitepaper: Micron
https://www.elpida.com/pdfs/E0598E21.pdf

Elpida Memory FAQ:
https://www.elpida.com/en/products/faq.html#tech-dr

Micron: Low-Power versus Standard DDR SDRAM
https://download.micron.com/pdf/technotes/DDR/tn4615.pdf 

LP-DDR2 - the new mainstream for embedded and mobile applications?
https://www.denali.com/wordpress/index.php/dmr/2010/05/20/lpddr2-the-new-mainstream-memory-for-emb 

Texas Instruments: Keystone Architecture for DDR3 Memory Controller
https://www.ti.com/lit/ug/sprugv8c/sprugv8c.pdf 

Wiki: Mobile DDR
https://en.wikipedia.org/wiki/Mobile_DDR 

ELPIDA: Low power function of Mobile RAM
https://www.elpida.com/pdfs/E0597E10.pdf 

Research Paper: Trends in Low Power RAM circuit technologies
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=371965 

Data Sheets for LP-RAM from Micron
https://www.micron.com/products/dram/mobile-lpdram#fullPart&306=0

Digging in:

When an application is launched the required code and data pages are unlikely to be read from contiguous locations on the storage device. More often than not part of the file is read, then other parts in the same file, parts of other required files and maybe other parts of the original binary.
 
In terms of application performance and startup time this is undesirable because the jumping between distant locations on storage slows application startup time considerably. The cost of retrieving random IO compared to sequential IO can be significant.

How significant?

Well, take a look at notepad:

There are parts of 30 binaries in the notepad address space. 30 files we needed to find on the disk!

Consider the (worst case) scenario where none, or very few of the binaries already reside in memory and none of them sit contiguously on disk. Lets say the disk has 10ms of seek latency...

30 x 10ms = 300ms of seek latency just to find the pages required to start the application because we are jumping all over the disk looking for the pieces required by the process.

Of course, the example is oversimplified - there may be pages already resident in memory which can soft faulted into the process address space; not all the process binaries in the diagram are needed for launch, and there are other optimizations at play. (Also, even with prefetch, the IO is not necessarily contiguous in terms of physical location, however, the IO is issued sequentially).

But the example gives you an idea of the problem application prefetch is intended to solve. Also keep in mind that notepad is a simple application... take a look at outlook.exe or internet explorer to see a real list of binaries in a process address space. 

(Note: Solid State Disks [SSD's] come up a lot when discussing this feature. Issuing sequential IO is still very beneficial to SSD even without the rotational latency mentioned above. This is especially true on a busy device where we want to get all the startup IO into the queue together)
 
Anyway - To improve application launch experience the Applaunch Prefetch component was implemented way back in Windows XP as a component of the Sysmain Windows service (%systemroot%\System32\Sysmain.dll).
 
Applaunch prefetch attempts to improve startup time by optimizing the startup IO of windows applications. Prefetch optimizes for more sequential IO by reading the initial application IO in large efficient batches.
 
Prefetch achieves this optimization by monitoring the code and data required for an application to launch. The prefetcher monitors up to the first 10 seconds of application startup with heuristics to stop sooner if the launch is completed sooner (when the application stops faulting pages).
 
The prefetch trace data is then written to a per-application file in %systemroot%\Prefetch.
 
The trace file names in the prefetch directory are comprised of the application name with a hexadecimal representation of the file path (hash) and a .pf extension.

For example: c:\windows\Prefetch\WINWORD.EXE-2437DA78.pf.

Trace files (.pf) describe the pages that were historically accessed by the application during launch.

You can use Mark Russinovich' s strings application to inspect a prefetch file if you are interested.

This is the notepad.exe example from above:

When an application is launched the prefetcher looks in the prefetch directory to determine whether a .pf file is present for the application.

If the .pf file exists, the kernel component of the prefetcher issues asynchronous IOs to prefetch metadata, data, and image pages described in the trace file (.pf file).

In an effort to further optimize performance, every 72 hours during system idle time the Sysmain service provides information that can be used by the system defragmenter. The information is provided to enable defrag to physically order files and directories in the order they are referenced during application launch. This order is stored in the %systemroot%\Prefetch\Layout.ini file.

The Sysmain service does not run defragmentation, it only provides data for systems that have defragmentation enabled (SSD's have defrag off).

And that's the bulk of it.

The impact is pretty big. In some recent tests we saw between 10% and 80% improvement in application launch times across multiple devices, multiple applications, with multiple configurations doing all sorts of different things. 

Interestingly, the biggest improvements are when devices are under a heavy IO load. The smallest gains are on SSD devices with no load at all. Issuing the IO in large contiguous chunks is very beneficial for application launch because the application is not constantly waiting in line behind other IO every time it needs to jump to a different binary. 

You could think of it as: One person waiting in line to buy movie tickets for the whole family rather than each person doing it individually. (Especially if they turn up a few milliseconds seconds apart and having a random stranger jump into the line between you).

In the good scenario, you turn up at the counter with your five ticket requests and they are all completed at once. You head on in to the cinema, happy days.

In the bad scenario, you line up and get your ticket. Then you have to wait on your wife, who is behind some dude deciding between pop corn and a chock top. Then, you both have to wait on your son who is behind three other folk in the line... etc. Its going to take a while before you get in to the cinema because you all have to go together.

Well, its roughly the same deal for your application launch IO. We cant start till we fetch all the pages we need for launch.

Have a great weekend.  

This was partly because I wasn't paying attention, partly because i didn't allocate time, but to be honest, partly because the simple app generator tool mentioned in the previous post allowed me to create an application that failed the assessment.

(Your application goes through assessment when you try to publish it to the store).

The first two problems are mine to fix up.

The third problem i wanted to touch on quickly since i posted how "easy" it was to get an application in the store, and how "anyone" could do it. And i managed to mess it up.

For the most part, i still maintain its pretty simple using the tool - but here are some extra caveats:

1. The tool will allow you to make mistakes. Not many, but its possible. (My mistake was choosing a background that actually made some of the content unreadable if a person had their phone set up a certain way).

2. You still need to know how to take some screenshots of the application to include with your store submission. (I failed to do this, and i failed to write it in the previous post).

The good news is, for every mistake you make, the submission people send you a "how to" on fixing the problem. It comes in a very easy to read .pdf that explains it all.

The down side is that you might have a couple of days wait while the review happens.

Anyway - the final result of the "30 minute app" is here:

https://www.windowsphone.com/s?appid=1d4c4ece-97fc-4d2b-98d1-93deb5fe46c7

Its not much to look at, but it was great to be able to follow the create -> submit -> publish process with an easy example.

Looking forward to adding some real functionality to the app at some point, but i can see how it would be very useful for small business to get up and running quickly.

So easy, you could do it with your kids, this weekend, in less than an hour. (30 minutes if you aren't doing chocolate milk & cookie breaks while you work).

HUGE CAVEAT: Be realistic, it wont be the next Angry Birds, it probably wont make you rich. The next Angry Birds is probably not going to happen in an hour, without tools, in your browser, drinking chocolate milk and eating cookies. But, your application will look slick and it will be available in the store to show your mum/dad/wife/etc very soon after you finish it.

If you have a small business, an application is a great way to promote it.

[By the way, I completely understand that this isn't a Kernel topic at all. I just wanted to share the experience in case anyone else was up for an hour of fun that has nothing to do with our day job.]

First step - Go to this site:

https://appstudio.windowsphone.com/

In truth, that's very close to all you need from this post. You essentially follow the prompts from that point onwards. But let me share the application my five year old son and I just built.

The application is just a simple interface to this site. (I couldn't think of anything more creative this high up in the stack).

The site:

Log in, and then choose a template for your application...

I just choose blank. The UI to drag and drop content from the blank template is very easy. But, if you would prefer, there are templates for restaurant menus, fitness plans, goals, all sorts of stuff.

Once you choose a template you can select where to pull data from. In my case, this blog website using RSS. If you want, you can just add static data as well and just republish the application when you want to change it.

Then you start to navigate through the bits and pieces about colors, fonts etc.

(Yes, i know this blog is really, boringly simple... i just wanted to share how easy it actually is to get something in the store you can have your friends download and use).

Once you have colors, content, layout done all you need to do is choose some publishing information and whether you want ads in your application (to make some cash) and boom, you are just about done.

Choose finish and you will be prompted on which type of application you want to generate.

(I chose Windows Phone 8 for simplicity)

Right at the end, after your application has finished generating it gets slightly trickier if you haven't published an application before. Its not a big deal, it is because you need to know how to take the application package and move it to the Windows store.

Its not difficult, just something you mess about with once and then its pretty simple from that point onwards.

(If you want to,you can install the application on your phone, or friends phones by providing a certificate rather than using the store at all. But to get it in the store, you have to download the publish package and submit it to the store as an application.)

To get the application into the store, download the "publish package":

Once you have the package, go to the phone developer site.

https://developer.windowsphone.com/en-us

There is a link that says "submit an app"

You will see a heap of options, but you can scroll past most of them and down the bottom you will be prompted to "agree to continue" (of course, read all the terms etc. first).

If this is your first time developing something for the Windows Store you might be prompted to set up some account details.

Once you are done, you will arrive at this screen:

Once again, click "submit app" and then start to fill out the details of the application.

Eventually, you will be prompted to provide the package you downloaded - the "publish package".

Mine looks like this:

You will choose the markets it should go to (Australia, US, Canada etc.), and then type of application category your application belongs to. There are few other details but it is all fairly intuitive stuff.

Once you answer all the questions, you are done:

Within a few hours, you should have an application to try out.

I will upload mine on this blog once it hits the store.

Angry Birds riches here i come!

Thanks,

Chad

The topic is reasonably interesting on its own because you can start to mess about in there, especially if you crack open the in-built help (not kidding, it is an exceptional help file) to start exploring.

So, the thing is, when we attach the debugger to the system we take control but the target appears frozen while we are broken in. Wouldn't it be cool if we could just let the system run as normal until it arrived at the spot we were interested in? Potentially we could just keep using the system as normal till it does that thing that has been irking you.

The next logical step then - is to explore the system using breakpoints!

For example, say we want to explore what happens when we create files in Windows...

Well, MSDN tells us one function that can be used to create files is ntCreateFile (or zwCreateFile). MSDN tells us this here: https://msdn.microsoft.com/en-us/library/windows/hardware/ff566424(v=vs.85).aspx

Then - lets do a breakpoint for that function so we can just break in right when the system is doing that stuff...

Example:

1. Break into the system using the techniques in the previous post: https://bit.ly/MYhESc

2. At the debugger type bp zwcreatefile

3. Now hit g to let the system run. The plan is, if the debugger notices that function being called we should break in at that point and we can dig around and learn about the function and how it works.

In this example, the function is called and the debugger breaks in.

We can have a dig around using commands like k to display the call stack or ub to "unnasemble backwards" (unassembled the current function backwards and display the instructions - in this example we have picked up the PfQuerySuperFetchInformation function and you can see if calling the NtCreateFile function). We will do some messing around with debugger commands in another post shortly.

That's about it, setting a breakpoint is fairly simple if you know the function you are interested in.

Oh! To remove the breakpoints type bd * to clear them all, or bd "{function}" to disable (bd == breakpoint disable) that one. You can also use bl to list the breakpoints that are currently set.

Thanks!

Chad

1.  Enable debugging on the Windows guest machine.

2. Change the VM settings to support debugging via named pipe.

3. Configure your debugger and break in.

Longer Version:

1. Enable debugging on the Windows guest machine.

This assumes you have a Windows virtual machine already built and running. You also need administrative privileges and a reboot will be required.

Open an administrative command prompt and type:

bcdedit /set debug on

If you want to check - type bcdedit on its own and you should see debug - Yes.

Reboot the machine.

2. Change the VM settings to support debugging via named pipe.

Open the HYPER-V Console and find the machine you wish to debug. (Similar process for other VM platforms).

Open the virtual machine settings and find the COM settings.

Choose the option for a "named pipe".

It doesn't matter too much what you call the pipe, once you type something it will tell give you a path to the pipe which you can use in your debugger. This will be important for step 3.

In my example: \\.\pipe\dbg

3. Configure your debugger and break in.

You need to install a debugger. I find windbg useful for what i do, but the choice is yours. It has a next > next > next style install so i wont waste your time here. Once it is installed we are ready to roll.

Open the debugger elevated so that you can get access to the guest machine running on the host.

Choose File > Kernel Debug and locate the tab that says COM

This is where you type the path that the virtual machine COM settings gave you. In my example it was \\.\pipe\dbg

When you hit ok, the debug will attempt to attach to your virtual machine.

If you get an error - check that you used an elevated version of the windbg process and check the Port (pipe) path. Also make sure you ticked "pipe" in the debugger like the image above.

At this point, the machine is ready for you to break in. If you hit the icon with the blue squiggly lines (shown above) you take control of the machine and can start to mess around with the debugger. Remember, the machine will appear "frozen" while you are broken in because you are controlling the machine and stepping through instructions. If you want to let it proceed, just type 'g' for Go in the debugger.

If you want to break in again, just hit the break icon as before (or type ctrl-break)

Thanks,

Chad

Connected Standby devices can generally out-perform most non-connected standby devices in terms of power consumption while actually getting a small amount of critical work done while the screen is off.

With Connected standby Windows devices get a lot of the benefit you expect from a mobile phone.

Things like inbound Skype calls even while the device is in your backpack (fantastic when you are travelling overseas because roaming on your mobile phone is very expensive).

Also, your content stays up to date while the device is off (email, live tiles etc.) & the device resumes from screen-off exceptionally quickly.

The bit i have really come to depend on though, is that while i wander around campus from meeting to meeting, building to building, the device is joining the appropriate wireless networks as i go.

As soon as i open the device in my next meeting the device is ready to go. There is no waiting to get on a network, watching the little connection status icon spin for what seems like eternity (to be fair it is 20 or 30 seconds, but zero is much better).

With Connected Standby as soon as i open the device, it is ready to go and my content is fresh.

I really like this feature and i miss it when i pick up a non-connected standby device for the day.

If you have time, this video explains it much better in 2 minutes or less:

[View:~/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-01-70/What-is-Connected-Standby.mp4:0:0]

That's the cool parts of connected standby...

Up until 6 months ago i worked in a field role for Microsoft and i have been involved in a few conversations  involving negative connected standby experiences.

At the time, i didn't really understand what was going on. In most cases I had the customer routed to the correct support people to work it through. But now, six months into my role in the Kernel team I wanted to share some of the information i have picked up along the way in hope that it will help you with any trouble maker devices.

The first thing i wanted to call out is: if you aren't getting good battery life on a connected standby device - something is wrong. 

I can almost hear you saying "well done Captain Obvious!". But what i mean by that is, Connected Standby devices are engineered from the group up to be very good on battery, especially during standby.

If you bought a Connected Standby device, the hardware is more than likely the better stuff. Components like Memory of the DDR3-RS, DDR3L even LP-DDR3 flavor rather than normal PC-DDR. (will cover DRAM in another post shortly, or you can bing it). The device will most likely have low power networking components (both Bluetooth and WiFi, maybe even Mobile Broadband) and low power storage. The system most likely be designed around a low power SoC (System on a Chip).

If your device supports CS, you have a very good quality device in terms of hardware components.

(Want to be sure if your device supports CS? Launch an elevated command prompt and run "Powercfg /a". You are looking for output like that below)

Actually, for a quick detour: why wouldn't a device support connected standby?

The short answer is, its very difficult. But i gave a hint with the premium hardware comments above.

The hardware needs to be capable of supporting the new very low power states. At worst, the controllers must be able to deal with devices attached to the system that don't do well with low power. On top of that, the system as a whole needs to be able to communicate advanced power states to Windows through a driver called a PEP. The firmware of the devices often has specific modifications for low power activity. Generally speaking the device manufacturer needs to be thinking about CS right from the first blueprint.

Actually, a much better way to see what you might expect from the hardware is to watch this short video.

(Our team published these on MSDN only this week. They are short and interesting I promise):

[View:~/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-01-70/DPM.mp4:550:0]

(The video is available with some follow up text is here: https://msdn.microsoft.com/library/windows/hardware/dn481230(v=vs.85).aspx )

The main point: Connected Standby begins as a hardware feature.

Windows checks if the device manufacturer considers the device to be CS capable during system boot.

Windows reads the system firmware on the way up looking for an AOAC flag (AOAC == Always On Always Connected). If the firmware doesn't say AOAC, Windows doesn't implement the connected standby features. (Your device manufacturer supplies the firmware).

Windows also checks a few things itself. One of which, is that the device uses a solid state disk (SSD). It does this by checking whether the seek latency on the disk is greater than 0ms. Remember that seek latency is the time is takes the disk to find (not retrieve) the information you need. On a rotational disk this involves getting the disk platter to where it needs to be, and moving the head to the right spot. This takes time. On an SSD, there are no moving parts just an array of storage locations - we get 0ms 'seek' time.

Anyway, we are off track... What can you do if you are seeing battery drain that is out of the ordinary?

The good news is that there was a big chunk of work done during Windows 8.1 development that will definitely help out. 

The feature is called Sleep Study, and it is fairly easy to use and understand in most cases.

At its most simple, you just type: "Powercfg /sleepstudy" from a command prompt on your device. This will get you a HTML report which details where all your battery went and why.

The basics:

Up the top we get a graph showing all the charges and drains. Then we get a breakdown of every CS session over the last three days.

Each individual connected standby session has a hyperlink that leads to a more detailed section further down the document.

As an example, if i take Session 8 which shows me I lost 1% of my battery in 43 minutes and achieved a low power state only 89% of screen off time i could click for more detail:

In the example, I can drill in to see what things are going on in the background (BI == Background Infrastructure) and in the case i can see that there is some Skype, and some Windows Mail.

If i think about that, it makes sense that the network controller wouldn't go to sleep completely for about 8% of the time if i am doing a lot of mail and Skype. 

I will do a full post on sleepstudy with some solid examples shortly but I hope knowing about it gets some issues solved/understood in the meantime.

Depending on what the sleepstudy tells you there are some actionable things you can do:

- For some things, there will be a valid explanation. Maybe you are syncing a lot of mail or roaming between a lot of networks. Even then, the drain shouldn't be ridiculous though. There are heavy constraints on what the system is allowed to do and when (see the "Introduction to Connected Standby whitepaper). If the system appears to be just running flat out, something is wrong.

- Update your drivers. Bad drivers will never do on a Connected Standby system. Keep in mind that a connected standby system relies on drivers and firmware to tell Windows when to be in the lowest power state. To give a really tangible example, consider you network card firmware. On a Connected Standby system the firmware contains a list of the types of packets that should be allowed to wake the CPU with an interrupt and ultimately the rest of the system (think of a Skype call: push notification packet). If the firmware is bad, the system wont do well in Connected Standby because it may be woken up for all kinds of non-important traffic that is floating around wireless networks.  

- Make sure no drivers are missing. None. If you type "devmgmt.msc" at the start screen and find any yellow exclamation marks next to a device you have probably found the reason your battery is not doing well. The hardware components are tightly integrated on a Connected Standby system. One bad component may ruin the experience for an otherwise amazing device.

- Remove trouble maker applications from the lock screen. The applications configured as 'lock screen applications' on your system are allowed much more CPU and Network time during a CS session than others. As a test, remove any trouble makers you find using your sleepstudy report as a guide and see if Connected Standby gets better.

- Test with Airplane mode on. Just a test, not a long term solution. Airplane mode turns off the radio devices on the system. No radio devices, no inbound packets. Its a test that leaves the network interfaces in their lowest power mode. No roaming between networks, no push notifications. Its only a test though, if you find drastically improves the issue there is something unexpected going on that needs to be addressed.

- Test with "Quiet Hours". Background tasks and most notifications are suppressed during quiet hours. Default on Windows is 12 - 6am. See if extending this gives relief. Again, only for testing, not a long term solution.

Over the next few weeks i will cover off some more things like a detailed look at sleepstudy, some information about the guts of connected standby and try to keep a reference to any fixes i come across with either Microsoft updates or System Builder drivers and firmware if they are released.

For now, there is much more Information available:

Introduction to Connected Standby (Actually quite deep, originally for system builders):
https://msdn.microsoft.com/en-us/library/windows/hardware/dn481224(v=vs.85).aspx

Connected Standby User Experiences:
https://msdn.microsoft.com/library/windows/hardware/dn481217(v=vs.85).aspx

Applications and their impact on Connected Standby:
https://msdn.microsoft.com/en-us/library/windows/hardware/dn481223(v=vs.85).aspx

Thanks,

Chad