Microsoft Store blocked 

0x800704EC

Try to enable Microsoft Store using Group Policy Editor:

gpedit.msc

 Navigate to the following path on its left sidebar.

Computer Configuration\Administrative Templates\Windows Components\Store

locate the policy Turn off the Store application. Put right click on it and select Edit.
If the setting is “Enabled“, then modify its feature to either Not Configured or Disabled. Finally, make a hit on the Apply as well OK buttons to confirm changes.

Re-register Store through PowerShell
Re-registering the Microsoft Store will most probably resolve Error Code 0x800704EC Microsoft Store is blocked

This workaround with PowerShell cmdlet is the next:

Get-AppXPackage -Name Microsoft.WindowsStore | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register “$($_.InstallLocation)\AppXManifest.xml” -Verbose}

or

Windows 7 - drag and drop / copy and past don't/doesn't work

1)  Find an affected icon.(any in explorer or even in desktop)
2)  Click and HOLD the icon with the Left mouse button.
3)  Press Esc while holding the Left mouse button.

Drag and Drop Not Working in Windows 7

Go to Windows Explorer and click any file with any mouse button and keep the button held down for a few seconds.

Then press the Escape key. 

Drag and drop re-enabled. 
Is the miracle of Microsoft! :)

SQL join easy explanation . Left VS Rigth VS Inner VS Outter VS FULL

Winsock Event viewer tracing

Using Event Viewer to Start Winsock Network Event Tracing

When you open Event Viewer, the left pane contains the list of events. Open Applications and Services Logs and navigate to Microsoft\Windows\Winsock Network Event as the source and select Operational.

In the Action pane, select Log Properties and check the Enable Logging check box. Once logging is enabled, you can also change the size of the log file if this is needed.

Winsock network event tracing is now enabled and all you need to do is hit the Refresh action to update the list of events that have been logged. To stop logging, simply uncheck the same radio button.

You may need to increase the log size depending on how many events you want to see. One drawback to using the Event Viewer for Winsock tracing is that it does not load all the string resources so the messages displayed in the Description field (once you select an event) is sometimes hard to read (an argument that should be formatted as hex will be displayed in decimal, for example). However, you can select the Details tab in the event description which shows the raw XML log entry which usually has easier to understand arguments.

Using Event Viewer to Start Winsock Catalog Change Tracing

When you open Event Viewer, the left pane contains the list of events. Open Applications and Services Logs and navigate to Microsoft\Windows\Winsock Catalog Change as the source and select Operational.

In the Action pane, select Log Properties and check the Enable Logging check box. Once logging is enabled, you can also change the size of the log file if this is needed.

Winsock catalog change tracing is now enabled and all you need to do is hit the Refresh action to update the list of events that have been logged. To stop logging, simply uncheck the same radio button.

You may need to increase the log size depending on how many events you want to see. One drawback to using the Event Viewer for Winsock tracing is that it does not load all the string resources so the messages displayed in the Description field (once you select an event) is sometimes hard to read (an argument that should be formatted as hex will be displayed in decimal, for example). However, you can select the Details tab in the event description which shows the raw XML log entry which usually has easier to understand arguments.

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

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

Audit service start and stop

Like files and folders, services are access-controlled objects, and every access-controlled object has a security descriptor.

Part of a service's security descriptor is the system ACL (SACL), which you can use to track access to that object.

The only way to view or change a service's current SACL is through security templates.

To reach the security templates, log on to the server and open the Microsoft Management Console (MMC) Security Templates snap-in.
To create a new template, right-click on the security templates path.
Select New Template, click System Services, then double-click the appropriate service (i.e., Telnet). Select the Define this policy setting in the template check box, then click Edit Security to open the Security for Telnet dialog box.

This dialog box contains the service's ACL, which you can use to fine-tune who has start and stop authority.

Click Advanced, then select the Auditing tab in the Access Control Settings for Telnet dialog box.

As you can see, no auditing is currently enabled on the Telnet service because auditing isn't enabled by default.

Click Add, then add an entry to track successful start and stop events that members of Everyone initiate.
 Close all the dialog boxes, then save the template.
Import the template into the MMC Security Configuration and Analysis snap-in, then apply the template.
Now, you can check the Security log for event ID 560 (success audit: object open), where Object Type is SERVICE OBJECT, the Object Name is the short name of the service you're monitoring (in the case of the Telnet Service, TlntSvr), and the logged accesses include Start the service and Stop the service.



Source:
http://windowsitpro.com/systems-management/access-denied-auditing-users-who-might-be-starting-and-stopping-services

TCP retransmission

 You can increase this value with registry key TcpMaxDataRetransmissions

“This entry appears as MSS: (TcpMaxDataRetransmissions) How many times unacknowledged data is retransmitted (3 recommended, 5 is default) in the Local Group Policy Editor. This entry sets the maximum number of retransmissions of a TCP segment containing data before the connection is abandoned. The retransmission timeout is doubled with each successive retransmission on a connection. It is reset when responses resume. The base timeout value is dynamically determined by the measured round-trip time on the connection.”

You need to add this registry key

You can check more details in Microsoft online documentation:

http://technet.microsoft.com/en-us/library/dd349797%28v=ws.10%29.aspx#BKMK_4

http://support.microsoft.com/kb/170359

SQL 2008 -system queries

Execution Related Dynamic Management Views and Functions (Transact-SQL)

http://msdn.microsoft.com/en-us/library/ms188068%28v=sql.105%29.aspx



Usage:

select * from sys.dm_exec_xxxxxx

Using Performance Monitor to Find a User-Mode Memory Leak

If you suspect there is a user-mode memory leak but are not sure which process is causing it, you can use Performance Monitor to measure the memory usage of individual processes.
Launch Performance Monitor. Add the following counters:

• Process-->Private Bytes (for each process you want to examine)
  
• Process-->Virtual Bytes (for each process you wish to examine)
  

Change the update time to 600 seconds to capture a graph of the leak over time. You might also want to log the data to a file for later examination.
The Private Bytes counter indicates the total amount of memory that a process has allocated, not including memory shared with other processes. The Virtual Bytes counter indicates the current size of the virtual address space that the process is using.
Some memory leaks appear in the data file as an increase in private bytes allocated. Other memory leaks show up as an increase in the virtual address space.
After you have determined which process is leaking memory, use the UMDH tool to determine the specific routine that is at fault. For details, see Using UMDH to Find User-Mode Memory Leaks.

Using UMDH to Find a User-Mode Memory Leak

The user-mode dump heap (UMDH) utility works with the operating system to analyze Windows heap allocations for a specific process. UMDH locates which routine in a specific process is leaking memory.
UMDH is included in Debugging Tools for Windows. For full details, see UMDH.

Preparing to Use UMDH

If you have not already determined which process is leaking memory, do that first. For details, see Using Performance Monitor to Find User-Mode Memory Leaks.
The most important data in the UMDH logs are the stack traces of the heap allocations. To determine whether a process is leaking heap memory, analyze these stack traces.
Before using UMDH to display the stack trace data, you must use GFlags to configure your system properly. GFlags is included in Debugging Tools for Windows.
The following GFlags settings enable UMDH stack traces:

• In the GFlags graphical interface, choose the Image File tab, type the process name (including the file name extension), press the TAB key, select Create user mode stack trace database, and then click Apply.Or, equivalently, use the following GFlags command line, where ImageName is the process name (including the file name extension):
  
  gflags /i ImageName +ust 
  

• By default, the amount of stack trace data that Windows gathers is limited to 32 MB on an x86 processor, and 64 MB on an x64 processor. If you must increase the size of this database, choose the Image File tab in the GFlags graphical interface, type the process name, press the TAB key, check the Stack Backtrace (Megs) check box, type a value (in MB) in the associated text box, and then click Apply. Increase this database only when necessary, because it may deplete limited Windows resources. When you no longer need the larger size, return this setting to its original value.
  
• If you changed any flags on the System Registry tab, you must restart Windows to make these changes effective. If you changed any flags on the Image File tab, you must restart the process to make the changes effective. Changes to the Kernel Flags tab are effective immediately, but they are lost the next time Windows restarts.
  

Before using UMDH, you must have access to the proper symbols for your application. UMDH uses the symbol path specified by the environment variable _NT_SYMBOL_PATH. Set this variable equal to a path containing the symbols for your application. If you also include a path to Windows symbols, the analysis may be more complete. The syntax for this symbol path is the same as that used by the debugger; for details, see Symbol Path.
For example, if the symbols for your application are located at C:\MySymbols, and you want to use the public Microsoft symbol store for your Windows symbols, using C:\MyCache as your downstream store, you would use the following command to set your symbol path:

set _NT_SYMBOL_PATH=c:\mysymbols;srv*c:\mycache*http://msdl.microsoft.com/download/symbols 

In addition, to assure accurate results, you must disable BSTR caching. To do this, set the OANOCACHE environment variable equal to one (1). Make this setting before you launch the application whose allocations are to be traced.
If you need to trace the allocations made by a service, you must set OANOCACHE as a system environment variable and then restart Windows for this setting to take effect.
On Windows 2000, in addition to setting OANOCACHE equal to 1, you must also install the hotfix available with Microsoft Support Article 139071. This hotfix is not needed on Windows XP and later versions of Windows.

Detecting Increases in Heap Allocations with UMDH

After making these preparations, you can use UMDH to capture information about the heap allocations of a process. To do so, follow this procedure:

1. Determine the process ID (PID) for the process you want to investigate.
   
2. Use UMDH to analyze the heap memory allocations for this process, and save it to a log file. Use the -p switch with the PID, and the -f switch with the name of the log file. For example, if the PID is 124, and you want to name the log file Log1.txt, use the following command:
   umdh -p:124 -f:log1.txt 
   

3. Use Notepad or another program to open the log file. This file contains the call stack for each heap allocation, the number of allocations made through that call stack, and the number of bytes consumed through that call stack.
   
4. Because you are looking for a memory leak, the contents of a single log file are not sufficient. You must compare log files recorded at different times to determine which allocations are growing. UMDH can compare two different log files and display the change in their respective allocation sizes. You can use the greater-than symbol (>) to redirect the results into a third text file. You may also want to include the -d option, which converts the byte and allocation counts from hexadecimal to decimal. For example, to compare Log1.txt and Log2.txt, saving the results of the comparison to the file LogCompare.txt, use the following command:
   
   umdh log1.txt log2.txt > logcompare.txt 
   

5. Open the LogCompare.txt file. Its contents resemble the following:
   + 5320 ( f110 - 9df0) 3a allocs BackTrace00B53 
   Total increase == 5320 
   

   For each call stack (labeled "BackTrace") in the UMDH log files, there is a comparison made between the two log files. In this example, the first log file (Log1.txt) recorded 0x9DF0 bytes allocated for BackTrace00B53, while the second log file recorded 0xF110 bytes, which means that there were 0x5320 additional bytes allocated between the time the two logs were captured. The bytes came from the call stack identified by BackTrace00B53.
   
6. To determine what is in that backtrace, open one of the original log files (for example, Log2.txt) and search for "BackTrace00B53." The results are similar to this data:
   00005320 bytes in 0x14 allocations (@ 0x00000428) by: BackTrace00B53
   ntdll!RtlDebugAllocateHeap+0x000000FD
   ntdll!RtlAllocateHeapSlowly+0x0000005A
   ntdll!RtlAllocateHeap+0x00000808
   MyApp!_heap_alloc_base+0x00000069
   MyApp!_heap_alloc_dbg+0x000001A2
   MyApp!_nh_malloc_dbg+0x00000023
   MyApp!_nh_malloc+0x00000016
   MyApp!operator new+0x0000000E
   MyApp!DisplayMyGraphics+0x0000001E
   MyApp!main+0x0000002C
   MyApp!mainCRTStartup+0x000000FC
   KERNEL32!BaseProcessStart+0x0000003D 
   

   This UMDH output shows that there were 0x5320 (decimal 21280) total bytes allocated from the call stack. These bytes were allocated from 0x14 (decimal 20) separate allocations of 0x428 (decimal 1064) bytes each.
   The call stack is given an identifier of "BackTrace00B53," and the calls in this stack are displayed. In reviewing the call stack, you see that the DisplayMyGraphics routine is allocating memory through the new operator, which calls the routine malloc, which uses the Visual C++ run-time library to obtain memory from the heap.
   Determine which of these calls is the last one to explicitly appear in your source code. In this case, it is probably the new operator because the call to malloc occurred as part of the implementation of new rather than as a separate allocation. So this instance of the new operator in the DisplayMyGraphics routine is repeatedly allocating memory that is not being freed.
   

in http://msdn.microsoft.com/en-us/library/windows/hardware/ff545410%28v=vs.85%29.aspx


http://msdn.microsoft.com/en-us/library/windows/hardware/ff545405%28v=vs.85%29.aspx

Windows Task Manager columns description

What do the Task Manager memory columns mean?

http://windows.microsoft.com/en-us/windows/what-task-manager-memory-columns-mean#1TC=windows-7

In Task Manager, you can monitor processes running on your computer by adding columns to the information displayed on the Processes tab. These columns display information about each process, such as how much CPU and memory resources the process is currently using.

1. Open Task Manager by right-clicking the taskbar, and then clicking Start Task Manager.
2. Click the Processes tab. Task Manager shows the processes currently running under your user account. To show processes running for all users, click Show processes from all users.  If you're prompted for an administrator password or confirmation, type the password or provide confirmation.
3. To add more columns, click View, and then click Select Columns. Select the check boxes for the columns you want to see, and then click OK.
   
   

Column	Description
PID (Process Identifier)	A number that uniquely identifies a process while it runs.
User Name	The user account under which the process is running.
Session ID	A number that identifies the owner of the process. When multiple users are logged on, each user has a unique session ID.
CPU Usage	The percentage of time that a process used the CPU since the last update (listed as CPU in the column heading).
CPU Time	The total processor time, in seconds, used by a process since it started.
Memory - Working Set	Amount of memory in the private working set plus the amount of memory the process is using that can be shared by other processes.
Memory - Peak Working Set	Maximum amount of working set memory used by the process.
Memory - Working Set Delta	Amount of change in working set memory used by the process.
Memory - Private Working Set	Subset of working set that specifically describes the amount of memory a process is using that can't be shared by other processes.
Memory - Commit Size	Amount of virtual memory that's reserved for use by a process.
Memory - Paged Pool	Amount of pageable kernel memory allocated by the kernel or drivers on behalf of a process. Pageable memory is memory that can be written to another storage medium, such as the hard disk.
Memory - Non-paged Pool	Amount of non-pageable kernel memory allocated by the kernel or drivers on behalf of a process. Non-pageable memory is memory that can't be written to another storage medium.
Page Faults	The number of page faults generated by a process since it was started. A page fault occurs when a process accesses a page of memory that's not currently in its working set. Some page faults require page contents to be retrieved from disk; others can be resolved without accessing the disk.
Page Fault Delta	The change in the number of page faults since the last update.
Base Priority	A precedence ranking that determines the order in which the threads of a process are scheduled.
Handles	The number of object handles in a process's object table.
Threads	The number of threads running in a process.
USER Objects	The number of USER objects currently being used by the process. A USER object is an object from Window Manager, which includes windows, menus, cursors, icons, hooks, accelerators, monitors, keyboard layouts, and other internal objects.
GDI Objects	The number of objects from the Graphics Device Interface (GDI) library of application programming interfaces (APIs) for graphics output devices.
I/O Reads	The number of read input/output operations generated by the process, including file, network, and device I/Os. I/O Reads directed to CONSOLE (console input object) handles aren't counted.
I/O Writes	The number of write input/output operations generated by the process, including file, network, and device I/Os. I/O Writes directed to CONSOLE (console input object) handles aren't counted.
I/O Other	The number of input/output operations generated by the process that are neither a read nor a write, including file, network, and device I/Os. An example of this type of operation is a control function. I/O Other operations directed to CONSOLE (console input object) handles aren't counted.
I/O Read Bytes	The number of bytes read in input/output operations generated by the process, including file, network, and device I/Os. I/O Read Bytes directed to CONSOLE (console input object) handles aren't counted.
I/O Write Bytes	The number of bytes written in input/output operations generated by the process, including file, network, and device I/Os. I/O Write Bytes directed to CONSOLE (console input object) handles aren't counted.
I/O Other Bytes	The number of bytes transferred in input/output operations generated by the process that are neither a read nor a write, including file, network, and device I/Os. An example of this type of operation is a control function. I/O Other Bytes directed to CONSOLE (console input object) handles aren't counted.
Image Path Name	The location of the process on the hard disk.
Command Line	The full command line specified to create the process.
User Account Control (UAC) Virtualization	Identifies whether User Account Control (UAC) virtualization is enabled, disabled, or not allowed for this process. UAC virtualization redirects file and registry write failures to per-user locations.
Description	The description of the process.
Data Execution Prevention	Whether data execution prevention is enabled or disabled for this process. For more information, see What is Data Execution Prevention?

Silent instalation - InstallShield

Silent Install / Uninstall

---

A normal (non-silent) setup receives the necessary input from the user in the form of responses to dialog boxes. However, a silent setup does not prompt the user for input, it gathers setup data from the InstallShield Silent response file (.iss file).
A response file contains information similar to what an end user would enter as responses to dialog boxes when running a normal setup. InstallShield Silent reads the necessary input from the response file at run time. The format of response files resembles that of an .ini file, but response files have .iss extensions. A response file is a plain text file consisting of sections containing data entries. The best way to create an InstallShield Silent response file is to run the setup and have InstallShield automatically record and create the response file. If necessary, the response file can be manually edited after it is created.

Note

All passwords are saved in human readable form in the recorded silent setup file.

Command line switches for Setup.exe

/f1 or -f1

Specifies an alternate location and name of the response file (.iss file).

 If this option is used when running InstallShield Silent, the response file is read from the folder/file specified by.

 If this option is used along with the -r option, the response file is written to the folder/file specified by.

If no path defined it will be written at %windir%

/f2 or -f2

Specifies an alternate location and name of the log file created by InstallShield Silent.
By default, Setup.log log file is created and stored in the same directory as that of Setup.inx.

 

/r or -r

Causes Setup.exe automatically to generate a silent setup file (.iss file).

/s or -s

Runs InstallShield Silent to execute a silent setup.

Note

Separate multiple command line switches with a space, but do not put a space inside a command line switch (for example, /r /f1Install.iss is valid, but not /r/f1 Install.iss).

When using long path and filename expressions with switches, enclose the expressions in double quotation marks. The enclosing double quotes tell the operating system that spaces within the quotation marks are not to be treated as command line delimiters.

 

Create a response file

1. Open a DOS window (Command Prompt).
2. Type the directory path of the Setup.exe. If spaces appear in the path, place quotes around the path. For example:
   "C:\my setup dir\Setup.exe"
3. Type a space, then type the command line switches to use. For example:
   "C:\my setup dir\Setup.exe" -r -f1C:\MySilentFile.iss
   The above switches record a silent setup file to the file C:\MySilentFile.iss
4. Press Enter.
   The Setup program runs.
5. Complete the installation or uninstallation process as you normally would.
   All responses are recorded for use when Setup is run silently.

After the file is recorded, you can verify your responses by viewing the silent setup file in Notepad or Wordpad.

Install with the silent option

1. Open a DOS window (Command Prompt).
2. Type the directory path of the Setup.exe. If spaces appear in the path, place quotes around the path. For example:
   "C:\my setup dir\Setup.exe"
3. Type a space, then type the command line switches to use. For example:
   "C:\my setup dir\Setup.exe" -s -f1C:\MySilentFile.iss -f2C:\install.log
   The above switches read a silent setup file at the location C:\MySilentFile.iss
4. Press Enter.
   Setup runs silently without asking for user feedback.
5. Verify the process was completed properly. For example, if you used Setup to install LanSafe, be sure LanSafe is running properly.

Note

A Setup run in silent mode uses the same settings as the Setup you ran through to create the response file. Essentially, you are creating clone installations.

Troubleshooting errors

Setup.log is the default name for the silent setup log file that contains the results of the last run of a silent setup. This file is saved in the same location as the recorded .iss file. The result code shown in the file is one of the following:

0 Success.
-1 General error.
-2 Invalid mode.
-3 Required data not found in the Setup.iss file.
-4 Not enough memory available.
-5 File does not exist.
-6 Cannot write to the response file.
-7 Unable to write to the log file.
-8 Invalid path to the InstallShield Silent response file.
-9 Not a valid list type (string or number).
-10 Data type is invalid.
-11 Unknown error during setup.
-12 Dialog boxes are out of order.
-51 Cannot create the specified folder.
-52 Cannot access the specified file or folder.
-53 Invalid option selected.

Usually, errors occur because a specified command line switch is invalid or the .iss file has been manually edited incorrectly.

Shrinking of transaction log file and other maintenance DB best pratices

Shrinking of transaction log file

SQL Server cannot move log records from the end of the log file toward the beginning of the log file. This means that SQL Server can only cut down the file size if the file is empty at the end of the file. The end-most log record sets the limit of how much the transaction log can be shrunk. A transaction log file is shrunk in units of Virtual Log Files (VLF). You can see the VLF layout using the undocumented DBCC LOGINFO command, which returns one row per virtual log file for the database: 

DBCC LOGINFO('myDatabase') 

FileId	FileSize	StartOffset	FSeqNo	Status	Parity	CreateLSN
2	253952	8192	11	0	128	0
2	253952	262144	13	0	128	0
2	270336	516096	12	0	128	7000000025000288
2	262144	786432	14	2	128	9000000008400246

The interesting column is "Status". 0 means that the VLF is not in use and 2 means that it is in use. In my example, I have 2 at the end of the file (read result from top to bottom) and this means that the file cannot currently be shrunk. How to handle this depends on your recovery model. You should adjust and replace options and database appropriately for below code. If you are uncertain, then check the command in the product documentation:

• Simple recovery model
  USE dbname
  CHECKPOINT--First param below is fileno for log file, often 2. Check with sys.database_files
  --Second is desired size, in MB.DBCC SHRINKFILE(2, 500)DBCC SQLPERF(LOGSPACE) --OptionalDBCC LOGINFO --Optional
  Now repeate above commands as many times as needed!

• Full or bulk_logged recovery model
  USE dbname
  BACKUP LOG dbname TO DISK = 'C:\x\dbname.trn'--First param below is fileno for log file, often 2. Check with sys.database_files
  --Second is desired size, in MB.DBCC SHRINKFILE(2, 500)DBCC SQLPERF(LOGSPACE) --OptionalDBCC LOGINFO --Optional
  Now repeate above commands as many times as needed!

What you end up doing is empty the log (CHECKPOINT or BACKUP LOG) and DBCC SHRINKFILE several times, so that SQL Server can move the head of the log to beginning of the file and also so the end of the file becomes unused. Investigate the layout of the log file using DBCC LOGINFO in between.

In:

http://www.karaszi.com/SQLServer/info_dont_shrink.asp

Other references:

http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx