1. Find a location for your script/batch file.  Your documents library is a good place.
2. Create a new file and name it something like "StartApplications.bat". The most important thing is to make sure the extension of the file is ".bat" - you may need to make extension visible in order to do this.
3. Right-click the file and select "edit"
4. For each application you want to start, add a start command on a new line in the batch file.
   1. Type start "" <path to application>
   2. Replace <path to application> with an actual path
   3. Example: start "" "C:\Program Files\Microsoft Office\root\Office16\OUTLOOK.EXE"
5. Save the file
6. Hit the windows key and type "task"
7. Task scheduler should be the "best match" - hit enter
8. In the "Actions" pane on the right side, click "Create Task"
9. Enter a name e.g. "Start Applications"
10. Click on the "triggers" tab
11. Click the "new" button
12. Click the "begin the task" drop down and select "at log on"
13. Check "delay task for" and select a desired time. I used one minute.
14. Click "Ok"
15. Click the "actions" tab and click "new"
16. Click "browse" and navigate to your batch file you created
17. Click "ok"
18. Click "ok"

Office is an enormous collection of source code.  I have just about every data structure imaginable right at my fingertips.  Smart pointers, smart array handling, hashes, sets, and every other collection type.  Needless to say, I rarely every write a line of code that looks something like:

MyClass* pClasses = new MyClass[ 10 ];

It will always be wrapped in something like:

MyArrayHolder< MyClass > classArray( 10 );

STL provides similar functionality:

std::vector< MyClass > classVector( 10 );

These classes call new[] and delete[] for us.  A side effect of delete[] is that it calls the destructor (if destructible) on every object in the allocation.  Something like this:

MyClass* pClasses = new MyClass[ 10 ];
... Properly setup all 10 allocations ...
delete[] pClasses;

will lead to ~MyClass() getting called 10 times, one for each MyClass chunk in the array allocation.  How does it know?  Calling new[] puts a nice "count" variable at the beginning of the allocation (again, if it is destructible):

[count | MyClass1 | MyClass2 | MyClass3 | ... | MyClass10]

When new[] returns, it gives you a pointer to the start of MyClass1, not count.  On my 64-bit OS, count of 8 bytes which seems pretty reasonable.  Furthermore, delete[] is pretty smart.  You pass it the pointer to the beginning of MyClass1 and it will say, "Oh, this is destructible. That means I have a piece of memory allocated for the count at the beginning.  I need to delete that too!" And so, it adjusts the pointer appropriately and deletes the entire block.

As long as you don't do anything "strange", your collection data structure will handle calling new[] and delete[] on your objects.  Let's look at something strange, though.  There are cases when we don't actually want the destructor called on some of the MyClass allocations.  Let's say that we didn't fill them all in and they're left with garbage memory.  Calling a destructor on garbage memory is undefined behavior - aka crash incoming.  To handle this, we do everything in BYTEs.  This is completely valid:

BYTE* pBytes = new BYTE[sizeof(MyClass)];
MyClass* pMyClass = static_cast<MyClass>(pBytes);

By extension, you could imagine using this to allocate a large number of bytes to form a MyClass array.  The important thing to note here is that BYTE is not a destructible object.  There is no ~BYTE to call.  The allocator sees this so the memory allocation looks like this:

[BYTE1 | BYTE2 | BYTE3 | ... | BYTE_N]

There is no need to store the count because there's no destructors to call.  This is where the gotchas come in.  Imagine I then did something like this:

BYTE* pBytes = new BYTE[sizeof(MyClass)];
MyClass* pMyClass = static_cast<MyClass>(pBytes);

... tons of code, losing track of memory allocations ...
delete[] pMyClass;

What is the allocator going to do there?  I'm calling delete on MyClass which is destructible.  The pointer will get adjusted and, uh oh.  The pointer should not have been adjusted.  In my scenario, the allocator started yelling at me which is a bit scary.  It wasn't until a vastly more experience developer than I came and helped me debug this that we found my error.  He kindly described how new[] and delete[] worked with destructible objects and the world was saved.

Last night, her Bluetooth just stopped working.  When I went into device manager, there was no Bluetooth device to be seen.  Under Other Devices  I saw something like "Bluetooth and WLAN adapter".  After uninstalling the device drivers like every good Windows users knows how to do, I clicked "Update Drivers."  Unfortunately, I was met with "This device is not configured correctly. (code 1)."  I opened up the properties page for said device and it revealed that drivers were missing for the device. 

Admittedly, I was stumped.  I had never had to do anything additional for the plethora of Windows devices I have used or maintained over the years.  I downloaded the Surface Pro 3 driver pack from the Microsoft website.  I navigated to the Marvell\bt folder, right-clicked the INF file, and clicked "Install."  I went back to device manager, selected "update drivers", and manually selected the Marvell AVASTAR drivers I just installed.  Even this didn't work.  Now, I'm completely stumped.

However, it dawned on me as I searched the web for solutions to this problem that devices support a variety of drivers.  This is why BIOS can be shown on your high-tech monitor even though it hasn't loaded the more advanced drivers.  Your monitor supports some type of standard monitor drivers that everyone knows.  I don't know the specifics but I bet the functionality is quite simple but it succeeds in at least showing something on the screen.  Luckily, there is something similar to this for Bluetooth devices.

Enter the "Generic Bluetooth Driver."  Any respectable Bluetooth device would support such a driver with basic functionality.  I used this driver and it worked!  Here's how:

1. Hit the windows key to get to the Win8 start screen
2. Type "Device manager" and hit enter when it shows up in the search panel
3. Find your Bluetooth device
1. It may still have the bad drivers in use.  It would then be found under "Bluetooth".  Right-click every item under that node and select uninstall.  (DO NOT SELECT DELETE)
2. If you already uninstalled the drivers, you will most likely find the device under "Other devices"
4. Right-click the Bluetooth device and select "Update drivers"
5. Select "Browse my computer for driver software"
6. Select "Let me pick from a list of device drivers on my computer"
7. Select "Bluetooth" and hit next
8. Select "GenericAdapter" under Manufacturer
9. Select "Generic Bluetooth Adapter" under Model
10. Click next until it has installed the drivers

This should fix your problem!

https://msdn.microsoft.com/en-us/library/windows/desktop/ms686991(v=vs.85).aspx

Note that a fiber runs in the context of the scheduling thread.  Each thread may have multiple fibers and each fiber may have its own local storage.  If a thread only has one fiber, then thread and fiber local storages are identical.  For more information about fibers:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms682661(v=vs.85).aspx

Now, to the more interesting part, using the APIs.  Luckily, using the local storage is straight forward.

Process for using a local storage:

1. Initialize local storage to retrieve index using TlsAlloc()
2. Set values in local storage using TlsSetValue()
3. Retrieve values using TlsGetValue()

Allocate the thread local storage once for all threads.  Each thread uses the same index to set and retrieve values.

The first MSDN link has a great explanation on thread local storage.

bool fFlag = pMyClass->FGetSomeFlag();
if( fFlag )  // <-- Set breakpoint here
  DoSomething( pMyClass );

However, this doesn't work in all cases.  Suppose we want to know what the system call to ::GetTickCount() returns.  We don't have a variable to output and calling the function in the debugger (if it were even possible) would return inaccurate values.  We can use our handy registers to output the value of GetTickCount().  We know that the return value will be stuffed into the EAX (32bit) and RAX (64bit) registers.  Note, you can usually get away with using EAX on 64bit machines.  But, it's handy to know that the full 64bit value is in RAX.  Let's look at a little program to illustrate:

DWORD GetCurrentTickCount()
{
   return ::GetTickCount();
} // <-- Set when-hit breakpoint here with:
  // TickCount32: {EAX} TickCount64: {RAX}
 
bool FOddTickCount()
{
   return GetCurrentTickCount() & 1;
}
 
void main()
{
   for( int i = 0; i < 10; i++ )
      bool fOdd = FOddTickCount();
 
   return;
}

If you look at the assembly, you see that the debugger has the ability to set a breakpoint after the call to GetTickCount():

   return ::GetTickCount();
000000013FDF1045  call        qword ptr [__imp_GetTickCount (13FDFB300h)]  
} // <-- Set when-hit breakpoint here with:
000000013FDF104B  add         rsp,20h  
000000013FDF104F  pop         rdi  
000000013FDF1050  ret  

This allows us to set breakpoints after functions are called with return values.  When I run the small program, my debugging output window looks like:

TickCount32: 355088539 TickCount64: 355088539
TickCount32: 355088602 TickCount64: 355088602
TickCount32: 355088664 TickCount64: 355088664
TickCount32: 355088726 TickCount64: 355088726
TickCount32: 355088789 TickCount64: 355088789
TickCount32: 355088851 TickCount64: 355088851
TickCount32: 355088914 TickCount64: 355088914
TickCount32: 355088976 TickCount64: 355088976
TickCount32: 355089038 TickCount64: 355089038
TickCount32: 355089101 TickCount64: 355089101

I use this technique quite a bit, hopefully it helps.

Needless to say, I did check-in fixes and aided in lowering our bug count.  However, one fix wasn't done absolutely perfectly.  I don't remember the bug or the fix but I do remember the outcome.  It included something like:

MyPointerClass* pMyClass = GetMyPointerClass();
pMyClass->DoSomething();

My boss walked into my office with laptop on hand and a completely stern looking upon his face (he normally looks very calm and quiet).  Immediately, I felt my face go flush as I knew I was in trouble.  He pointed me to the bug I fixed and the code that I had changed.  He looked at me and said "You remember this?"  After acknowledging, he went on to explain that crash that I had caused.  If my face wasn't tomato red, it was now.  A null-pointer crash.  I learned how to avoid that in CS101.  What a stupid mistake!  He must have seen my embarrassment as he left my office say something like "it's ok this time, just remember for next time."

Lesson learned, everyone.  CHECK YOUR POINTERS!

Enter our scenario.  Say we have a ListBox filled with movie titles.  We bind our ListBox's DataContext to an ObservableCollection<MovieItem>.  We bind the title of the movie to the TextBlock in our ItemTemplate.  When our app boots, we load some fake movie data into our collection and our ListBox is automatically updated.

CODE:

public partial class MainPage : PhoneApplicationPage
{
   public MainPage()
   {
      InitializeComponent();
 
      // Create movie items
      for( int i = 1; i <= 10; i++ )
         m_movieList.Add( new MovieItem()
         {
            Title = "Saw " + i,
            Description = "This is a long description so that we can see it in the drop down menu. Sorry, I don't have anything better to say.",
            Duration = TimeSpan.FromHours( 2 )
         } );
 
      MovieListBox.DataContext = m_movieList;
   }
 
   MovieItemList m_movieList = new MovieItemList();
}
 
public class MovieItemList : ObservableCollection<MovieItem> { }
 
public class MovieItem
{
   public string Title { get; set; }
   public string Description { get; set; }
   public TimeSpan Duration { get; set; }
}

XAML:

<phone:PhoneApplicationPage.Resources>
   <local:MovieItemList x:Key="MovieItemListDataSource" d:IsDataSource="True"/>
</phone:PhoneApplicationPage.Resources>

...

<ListBox x:Name="MovieListBox" DataContext="{Binding Source={StaticResource MovieItemListDataSource}}" ItemsSource="{Binding}">
   <ListBox.Resources>
      <DataTemplate x:Key="DataTemplateMovie">
         <StackPanel>
            <TextBlock TextWrapping="Wrap" Text="{Binding Title}" VerticalAlignment="Top" HorizontalAlignment="Left"/>
         </StackPanel>
      </DataTemplate>
   </ListBox.Resources>
   <ListBox.ItemTemplate>
      <StaticResource ResourceKey="DataTemplateMovie"/>
   </ListBox.ItemTemplate>
</ListBox>

This works great.  However, we want to add some advanced functionality.  When an item in the ListBox is selected, we want to drop down a Panel that displays additional information like run-time and a description.  This means we need to know which ListBoxItem is selected.  We don't have the ability to use FindAncestor since we're in SilverLight.  This is where we get a bit creative.  First, we need to add what we'll call a drop down panel to our ItemTemplate.  We place an invisible StackPanel with two TextBlocks for the run-time and description.  When it is invisible, it does not take up any space in our ItemTemplate.  When we turn it visible, the ItemTemplate will grow and act just like a drop down menu.

XAML (add as a child of the title TextBlock):

<StackPanel x:Name="DropDownPanel" Margin="20,0,0,0" Visibility="Collapsed">
   <TextBlock Margin="0" TextWrapping="Wrap" Text="{Binding Description}"/>
   <TextBlock TextWrapping="Wrap" Text="{Binding Duration}" VerticalAlignment="Top" HorizontalAlignment="Left"/>
</StackPanel>

Now, we need to bind our ListBox's IsSelected to the visibility of the drop down panel.  Let's add a SelectionChanged event handler for our ListBox.  This gives us all the elements that were removed from and added to our selection.  First, we need to get the generated ItemContainer from each MovieItem.  Second, we need to walk our visual tree to find a drop down panel child.  Finally, we can simply toggle the visibility based on the item's selected status.

CODE (add to MainPage class):

void MovieListBox_SelectionChanged( object sender, SelectionChangedEventArgs e )
{
   MovieItem movieItem = e.AddedItems[ 0 ] as MovieItem;
   ListBoxItem item = MovieListBox.ItemContainerGenerator.ContainerFromItem( movieItem ) as ListBoxItem;
   StackPanel dropDownPanel = FindDropDownPanel( item );
   if( dropDownPanel != null )
      dropDownPanel.Visibility = System.Windows.Visibility.Visible;
}
 
StackPanel FindDropDownPanel( DependencyObject obj )
{
   const string dropDownName = "DropDownPanel";
   for( int i = 0; i < VisualTreeHelper.GetChildrenCount( obj ); i++ )
   {
      DependencyObject childObj = VisualTreeHelper.GetChild( obj, i );
      if( childObj != null && childObj is StackPanel && childObj.GetValue( NameProperty ).Equals( dropDownName ) )
         return childObj as StackPanel;
      else
      {
         StackPanel stackPanel = FindDropDownPanel( childObj );
         if( stackPanel != null )
            return stackPanel;
      }
   }
   return null;
}

Notice we made it specific to a StackPanel and we only did the first added item. This can easily be changed but was done for simplicity's sake. I'm sure this can be done in other ways but hopefully someone finds this simple method useful.

Often times, when I start investigating a bug, I know that a good place to start is when a particular class is being destructed.  Easy enough, place the breakpoint on your destructor.  However, what happens if you haven't created a destructor?  Easy enough, code one and rebuild.  One final problem, what happens if this given class lives in another component?  Let's look at a substantially worthless example that illustrates this point.

namespace ExtNS
{
   class ClassWithDestructor
   {
   public:
      ~ClassWithDestructor() {}
   };
 
   class ComponentClass : ClassWithDestructor
   {
   public:
      ComponentClass( int data ) : m_importantData( data ) {}
      int GetImportantData() { return m_importantData; }
   private:
      int m_importantData;
   };
}

void main()
{
   ExtNS::ComponentClass* c = new ExtNS::ComponentClass( 10 );
   delete c;
}

Imagine for a moment that this class resides in an external component and contains some important, vital data for our program.  Furthermore, consider that we have a bug where we have an invalid ComponentClass* and we want to know where our pointer is being deleted.  First, we do not have the source code for this external component.  Second and more important, the component class does not have an explicit destructor but its parent may.

Enter a nice feature in Visual Studio.  We know that if a destructor is not explicitly defined but a parent class does, the compiler will generate one for us.  We proceed with this knowledge.  Ensure that symbols are loaded for the given component's library or executable (an explanation of how to accomplish this is outside the scope of this post).  In the breakpoint window, click on the new dropdown and select "Break at Function..."  Mine maps to [Ctrl+d, n].  Now, we enter our generated destructor as the function: ExtNS::ComponentClass::~ComponentClass.

If the function is found, you will see it as valid in the breakpoints window.  Attach the debugger to a running instance and run the scenario.  The breakpoint will hit whenever our class is being destructed.  Obviously, we will not have the source code to see the breakpoint, but we can use the callstack to trace where we have stopped.