Satyem https://docs.microsoft.com/archive/blogs/satyem/feed.xml Wed, 17 Apr 2019 03:27:14 GMT en-US hourly 1 Variable Argument Functions https://docs.microsoft.com/archive/blogs/satyem/variable-argument-functions Mon, 11 Mar 2013 16:10:00 GMT https://blogs.msdn.microsoft.com/satyem/2013/03/11/variable-argument-functions/ Usually the functions defined in C/C++ take constant number of arguments which are decided while declaring the functions. Sometimes we do need the functions that can accept variable number of arguments, Printf() function is a great example of such functions.  Let's see how these functions work in terms of stack building and how they are able to retrieve the arguments passed from the  caller.

int Sum(int n, ...) is the declaration of one such variable argument functions. Just like any normal functions it can have any return type and any number of mandatory parameters of any type. The difference is in ellipsis ... which should be the last parameter to such a functions. Also there should be at least one mandatory parameter to the function, even if this placeholder parameter is not used it is required to access rest of the arguments.

The three macros that are used in function implementation to retrieve the arguments are va_start, va_arg, va_end. va_list is the type that is used to hold the information of variable arguments. This should be set by va_start before accessing any of the variable parameters. va_arg then uses this type to access the parameters one by one. va_end is called to stop the processing, it actually resets the va_list type which was set by va_start to hold the variable parameter information. Lets check one simple example:

int Sum(int n, ...)
{
       int sum=0;
       va_list vaList;
       va_start( vaList, n);
       for (int i=0; i<n; i++)
       {
             sum += va_arg(vaList, short);
       }
       va_end (vaList);
       return sum;
}

This program simply adds all the numbers passed to Sum function, the first mandatory parameter tells the number of variable arguments that are passed to the function. The implementation is simple, first the vaList is initialized using va_start function, then va_arg is used to fetch next variable argument and at the end va_end is called to reset the vaList.

There are few important things to notice here:

  • The function takes an argument which reflects the number of variable arguments passed to the function. Such information is required because the variable argument function has no way to figure out the number of parameters passed on its own. Number of parameters need not be passed by first argument, there can be any other logic used in the function implementation to identify the number of parameters, but it should be part of funciton implemenation it self.

 

  • va_arg takes a parameter which is the type of parameter that it is going to retrieve. This parameter is necessary because va_arg just goes one location up in the stack to search for the next parameter value. So it will fetch 8 bytes on 64bit process, and then return the right value using expected size. So this type needs to be used carefully. Incorrectly using the type parameter will result in  wrong result. For example if I used BYTE in place of Short in the above function to va_arg, I will only be adding the first 1 byte value of all the numbers passed, which will be incorrect if i wanted to have all the numbers upto 2 bytes.

 

  • va_start takes the name of the parameter which is immediately followed by ellipsis .... As mentioned earlier there can be more than one mandatory parameters to variable argument functions, and va_start expects the last mandatory parameter name so that it can identify from where in stack the variable parameter starts and it sets the va_list type to same location.

 Let''s take a look at all this in function disassembly and see how does it owrk, below is the disassembly of the above functin Sum(int n ,...). The comment line above the instructions explains the logic of program flow and variable parameter handling.

//Since the first four parameters are passed via registers, below four instructions will put these parameters to the stack homing space so that all the parameters are there on stack.

    5 000007f6`17231020 894c2408        mov    dword ptr [rsp+8],ecx
    5 000007f6`17231024 4889542410      mov    qword ptr [rsp+10h],rdx
    5 000007f6`17231029 4c89442418      mov    qword ptr [rsp+18h],r8
    5 000007f6`1723102e 4c894c2420      mov    qword ptr [rsp+20h],r9

// Adjust the stack for local parameters
    5 000007f6`17231033 4883ec28        sub    rsp,28h
    6 000007f6`17231037 c744240800000000  mov     dword ptr [rsp+8],0

// The first variable parameter that was passed via rdx is at rsp+38.  So rax now contains the location of first variable parameter. vaList will be set to this location as part of va_start call.
    8 000007f6`1723103f 488d442438      lea    rax,[rsp+38h]

 // rsp+10 has the vaList local variable and it has been assigned rax which has the location of first variable parameter.
    8 000007f6`17231044 4889442410      mov    qword ptr [rsp+10h],rax
    9 000007f6`17231049 c744240400000000  mov     dword ptr [rsp+4],
    9 000007f6`17231051 eb0a            jmp     vararg!Sum+0x3d (000007f6`1723105d)

// The loop starts
    9 000007f6`17231053 8b442404        mov   eax,dword ptr [rsp+4]
    9 000007f6`17231057 ffc0            inc     eax
    9 000007f6`17231059 89442404        mov    dword ptr [rsp+4],eax

 // The loop condition check

    9 000007f6`1723105d 8b442430        mov    eax,dword ptr [rsp+30h]
    9 000007f6`17231061 39442404        cmp    dword ptr [rsp+4],eax
    9 000007f6`17231065 7d53            jge    vararg!Sum+0x9a (000007f6`172310ba)
 

   11 000007f6`17231067 33c0            xor     eax,eax
   11 000007f6`17231069 85c0            test    eax,eax
   11 000007f6`1723106b 7420            je     vararg!Sum+0x6d (000007f6`1723108d)

 //here we call va_arg. This first fetches the location of current parameter

   11 000007f6`1723106d 488b442410      mov   rax,qword ptr [rsp+10h]

 // Adding 8 to current parameter location. So it will start pointing to next parameter.

   11 000007f6`17231072 4883c008        add    rax,8

// Stored the location of next parameter to va_list

   11 000007f6`17231076 4889442410      mov    qword ptr [rsp+10h],rax
   11 000007f6`1723107b 488b442410      mov    rax,qword ptr [rsp+10h]

 // Since the location already points to next parameter, we need to subtract 8 to get the value of current variable parameter.  

   11 000007f6`17231080 488b40f8       mov     rax,qword ptr [rax-8]

 // So now rax contains full 8 byte. But we are using Short type in va_arg macro, so only need ax part of  it(i.e. 2 bytes)
   11 000007f6`17231084 0fb700          movzx   eax,word ptr [rax]
   11 000007f6`17231087 66890424        mov    word ptr [rsp],ax
   11 000007f6`1723108b eb1b            jmp     vararg!Sum+0x88 (000007f6`172310a8)

// Some instructions which are not relevent to variable argument handling are reomved from here to shorten the output 

//Adding to current sum.

   11 000007f6`172310b0 03c8            add     ecx,eax
   11 000007f6`172310b2 8bc1            mov     eax,ecx
   11 000007f6`172310b4 89442408        mov    dword ptr [rsp+8],eax

 //Looping again.

  12 000007f6`172310b8 eb99            jmp     vararg!Sum+0x33 (000007f6`17231053)

 // This is the code for resetting the vaList using va_end. As we know rsp+10 have vaList.
   13 000007f6`172310ba 48c744241000000000 mov   qword ptr [rsp+10h],0
   15 000007f6`172310c3 8b442408        mov    eax,dword ptr [rsp+8]
   16 000007f6`172310c7 4883c428        add  rsp,28h
   16 000007f6`172310cb c3              ret

 

This is an example from AMD64 process, as you can see the caller has no changes in it whether it is calling a normal functions or a variable argument function. It will pass all the parameters and will clean the stack when callee returns. So it is the responsibility of caller to clean up the stack, which is always the case in 64 bit functions. For 32 bit functions there are multiple calling conventions like STDCALL, CDECL etc. Among these CDECL is the one in which Caller cleans up the stack, so for 32 bit variable argument functions, the function should always be declared as __cdecl function.

 

 

 

]]> Debugging Windows Service https://docs.microsoft.com/archive/blogs/satyem/debugging-windows-service Sat, 23 Feb 2013 10:39:00 GMT https://blogs.msdn.microsoft.com/satyem/2013/02/23/debugging-windows-service/ From Vista onwards all the services run in Session 0, and session 0 has no interaction with desktop, this is named as session isolation and was added for security reason to windows. This brings a problem when we try to debug a service start up from a user session, if the service is already running one can attach the debugger and start debugging it, but attaching the debugger at startup becomes a problem.

Image File Execution option is the way to go:

  • Run regedit.exe
  • Goto HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
  • Create a new key for your service executable (example: myService.exe)
  • Create a new string value under your exe. The name of the string value is 'Debugger', and the value is debugger path like 'c:\debuggers\windbg.exe'

There still is a problem with this, when the service starts it will be started under debugger but you wont be able to see the debugger because it runs in session 0 and session 0 has no interaction with desktop. There are two ways to solve this problem:

1. Change the services properties and allow it to interact with desktop.  This can be done from registry or services.msc-> service Properties or can be passed as an argument in CreateService API. However some services might not be happy if you change their property, in that case you should chose second option.

2. Second option is to configure remote debugger session. While setting the registry for IFEO as above, add the command line parameter -Server TCP:Port=<ANY PORT> to windbg.exe.  (e.g. "C:\debugger\Windbg.exe" -server tcp:port=5555). Doing so will not only start the service under debugger but also start a server session for windbg, that can be connected from user session. Now from any user session you can start windbg and connect to the session 0 debugger using 'Connect to a remote session ' option in windbg.

Before you can happily debug the service now, you need overcome one last problem. And the problem is services timeout, if you start debugging the service you will find that after 30 seconds service is automatically killed and you can't debug after that. So who killed the service? Answer is SCM. SCM starts the service and expects that service should signal within 30 seconds that it is running happily, if the service doesn't respond within that time(which it ofcourse will not, if you are debugging it from its startup), SCM assumes that something bad(like a hang or crash) happened with the service, and it will terminate the service. So the solution to this problem is to increase the timeout from 30 seconds to some other good value that is long enough for you to debug the service.

To increase the timeout, create a new DWORD value ServicePipeTimeout under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control, and set a new timeout value. SCM reads the value as in miliseconds. You would need to restart the machine inorder to make the setting effective.  Make sure that you revert back the timeout value once you are done with debugging because this is a global setting and is applicable to all the services.

 

 

 

]]> Switching between User and Kernel space https://docs.microsoft.com/archive/blogs/satyem/switching-between-user-and-kernel-space Tue, 04 Sep 2012 12:03:00 GMT https://blogs.msdn.microsoft.com/satyem/2012/09/04/switching-between-user-and-kernel-space/
Revising the concept of switching from User to Kernel mode.
The different modes processor run into on windows OS. that is kernel mode and user mode.
We also say it ring0 and ring3 execution...
So there are many places when the OS
switches from User Mode to Kernel Mode or from Lower Privilege level to high
privilege level and vice versa. Examples are:
> Interrupts
> Exceptions
> System Calls

I would go in details with System calls today. We know that when we call a windows API from User mode, ntdll makes the
transition to kernel mode API and after the kernel completes the function call results are returned back to User mode.

For our example let's take
ntdll!NtReadFile. Any user mode read file operation would result in this API and
subsequently transferred to Kernel mode. let's check what is inside this function. Below is the disassembly of this fucntion:

mov    
r10,rcx
mov     eax,3
syscall
        
ret

You can notice the syscall instruction, this instruction is the one
that makes a fast call to kernel mode. Just for the information, this output is
from a X64 based PC.
X64 based CPU only support Syscall for 64bit mode and
not in compatibility mode. 
So what processor does when it sees the Syscall
instruction. Here are the steps directly from intel manual.
For Syscall the processor Saves the RFlags to R11 and RIP of the next instruction to RCX.

Now to run the kernel mode code:
the processor should have following piece of information:

Target Code Segment (CS) Target Instruction (where the execution should start)
Stack Segment
and System Flags.
This all it gets from CPU specific Registers.

CS = IA32_STAR[47:32]
RIP = IA32_LSTAR
(64bit Canonical address)
SS = IA32_STAR[47:32] +8
System Flags: processor
sets the system flags to the logical AND of its current value witht the
complement of the value in IA32_FMASK_MSR.

IA32_Star* basically are
MSRs(Model Specific Registers) and you can check the value of those using rdmsr
windbg command if you know the index of these registers(which you can easily
find in the Processors's manuals). The index for IA32_star is C0000081 for
example. C0000082 for IA32_LSTAR and C0000084 for IA32_FMASK.

when I checked on my box I found that RIP = IA32_LSTAR  this is the address of
nt!KiSystemCall64.
So now you know where the call will go when Syscall instruction is executed. You should also notice that this is the kernel function
called for any system call and not just ntdll!ntreadfile.

Once in kernel, the nt!nt!KiSystemCall64 decides what to do (which api to call based on
the parameter it received from user mode. I will explain next where this parameter is coming from?)
Kernel stack is stored in the TSS of every task and is fetched from there. The User stack and RIP , RFlags etc are stored in the
stack so that when the call returns to the user mode they can be restored.


When I said the argument is passed from user mode, to identify which
system call will be invoked in kernel mode, that argument basically is set into
Eax register right before the Syscall instruction.

mov r10,rcx
mov
eax,3
syscall
ret

Then corresponding to this number
3 we would need the API from system service table. On 64bit OS windows keeps the
offset of System Service calls, these offsets are 32 bits and are relative to
nt!kIServiceTable. So if you have to find the address of a specific service
routine. pick out the offset from the array nt!KiServiceTable and add that to
the base address of nt!kiServiceTable.
Hang on, there is a slight change in my above
statement. You should not directly add the offset to get the system service
address. Rather there is a trick used by Kernel. Kernel actually does not use all bits to store the offset. Last few bits are used for the number of arguments to
that system call.

We can check here the user mode ReadFile ultimately
goes to Kernel Mode nt!NTReadFile. Ok so what next. What if Nt!ntReadfile takes
some arguments, where do they come from? How does kernel receive them from user
mode? How does the control goes back to User mode once the systme call completes
its job? We will look at all these details in the next post.

]]> Thread's Stack https://docs.microsoft.com/archive/blogs/satyem/threads-stack Mon, 13 Aug 2012 20:52:00 GMT https://blogs.msdn.microsoft.com/satyem/2012/08/13/threads-stack/ Let’s talk about the thread’s stack today. Each thread has its own user mode and kernel mode stack which grows on demand. When a binary is built, linker inserts the default size for the stack into the PE header of binary. These default settings can be overridden by giving different values with /STACK option.  Below is a snip of PE header file of a test executable ThreadStack.exe:

0:000> !dh ThreadStack.exe -f

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES

     14C machine (i386)

       5 number of sections

4F8A2827 time date stamp Sat Apr 14 18:45:11 2012 

       0 file pointer to symbol table

       0 number of symbols

      E0 size of optional header

     102 characteristics

            Executable

            32 bit word machine 

By default the size of stack is 1 MB, however full 1MB is not committed at the beginning but only reserved. As the stack grows, more memory is committed and the amount of memory that is committed is size of Stack commit (1000) as shown above.

After reserving the 1 MB of memory for stack, system commits first 2 pages (i.e. 8KB) and assigns a guard attribute to second page.  Thread starts executing from the first page and as soon as it hits the guard page, system is notified. System then removes the guard attribute from the second page, commits another page of stack memory and assigns the guard attribute to that new committed page. As the stack grows, every time a new page is committed as soon as thread hits the guard page. The last three pages of stacks are treated a little differently; I will talk about that a little later.

Let’s see the stack status of ThreadStack.exe program when the recursive function has iterated a few times. ThreadStack.exe is a simple recursive program that causes stack overflow:

 /*ThreadStack.cpp*/
int RecurseFunction()

{

       int arr[200];

       //cin>>arr[0];

       RecurseFunction();

       return 1;

}

 int main()

{

       RecurseFunction();

       return 1;

}

0:000> kL

ChildEBP RetAddr 

0024eef8 00f0102e ThreadStack!RecurseFunction

0024f228 00f0102e ThreadStack!RecurseFunction+0xe

0024f558 00f0102e ThreadStack!RecurseFunction+0xe

0024f888 00f0102e ThreadStack!RecurseFunction+0xe

0024fbb8 00f01048 ThreadStack!RecurseFunction+0xe

0024fbc0 00f011d9 ThreadStack!main+0x8

0024fc08 76c81114 ThreadStack!__tmainCRTStartup+0x10b

0024fc14 776bb299 kernel32!BaseThreadInitThunk+0xe

0024fc54 776bb26c ntdll!__RtlUserThreadStart+0x70

0024fc6c 00000000 ntdll!_RtlUserThreadStart+0x1b

 

The thread environment block contains the Thread’s stack information:

0:000> !teb

TEB at 7ffdf000

 

0:000> dt _NT_TIB stackBase StackLimit 7ffdf000

ThreadStack!_NT_TIB

   +0x004 StackBase  : 0x00250000 Void

   +0x008 StackLimit : 0x0024e000 Void

 

0:000> r esp

esp=0024eefc

 

The stack base is the base address of first page from where the thread started andb stack limit is the last valid address on the current committed page being used. The snapshot of stack at this point can be represented as below

Let’s check the status and protection attribute of these pages from debugger, as the above picture depicts the first two pages are committed and third page is committed but has a guard attribute set. The fourth page is reserved but not committed.

0:000> !vprot 0x0024f000

BaseAddress:       0024f000

AllocationBase:    00150000

AllocationProtect: 00000004  PAGE_READWRITE

RegionSize:        00001000

State:             00001000  MEM_COMMIT

Protect:           00000004  PAGE_READWRITE

Type:              00020000  MEM_PRIVATE

 

0:000> !vprot 0x0024e000

BaseAddress:       0024e000

AllocationBase:    00150000

AllocationProtect: 00000004  PAGE_READWRITE

RegionSize:        00002000

State:             00001000  MEM_COMMIT

Protect:           00000004  PAGE_READWRITE

Type:              00020000  MEM_PRIVATE

 

0:000> !vprot 0x0024d000

BaseAddress:       0024d000

AllocationBase:    00150000

AllocationProtect: 00000004  PAGE_READWRITE

RegionSize:        00001000

State:             00001000  MEM_COMMIT

Protect:           00000104  PAGE_READWRITE + PAGE_GUARD

Type:              00020000  MEM_PRIVATE

 

0:000> !vprot 0x0024c000

BaseAddress:       0024c000

AllocationBase:    00150000

AllocationProtect: 00000004  PAGE_READWRITE

RegionSize:        00001000

State:             00002000  MEM_RESERVE

Type:              00020000  MEM_PRIVATE

 This way the stack keeps growing but in the last three pages system does things a little differently. When the program access the 3rd page from end as usual system is notified and system removes the Guard attribute from this page, commits the next page BUT this time it doesn’t apply the guard page attribute to the newly committed page(second last page). Also after committing the new page system raises a stack Overflow exception which you can catch if you are running the program into debugger. Let’s see this in our program threadstack.exe.

 0:000> g

(1284.96c): Stack overflow - code c00000fd (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

eax=004720d0 ebx=7ffd9000 ecx=00000001 edx=776a6194 esi=00000000 edi=00000000

eip=00f01029 esp=00152ed0 ebp=001531f8 iopl=0         nv up ei pl nz na po nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202

ThreadStack!RecurseFunction+0x9:

00f01029 e8d7ffffff      call    ThreadStack!ILT+0(?RecurseFunctionYAHXZ) (00f01005)

0:000> !error c00000fd

Error code: (NTSTATUS) 0xc00000fd (3221225725) - A new guard page for the stack cannot be created.

 Below output shows that no guard attribute is set to second last page:

 0:000> !vprot 0x00151000

BaseAddress:       00151000

AllocationBase:    00150000

AllocationProtect: 00000004  PAGE_READWRITE

RegionSize:        000ff000

State:             00001000  MEM_COMMIT

Protect:           00000004  PAGE_READWRITE

Type:              00020000  MEM_PRIVATE

 

0:000> !vprot 0x00150000

BaseAddress:       00150000

AllocationBase:    00150000

AllocationProtect: 00000004  PAGE_READWRITE

RegionSize:        00001000

State:             00002000  MEM_RESERVE

Type:              00020000  MEM_PRIVATE

 At this point the stacklimit would be the last address in second last page.

 0:000> dt _NT_TIB stackBase StackLimit 7ffdf000

ThreadStack!_NT_TIB

StackBase:            00250000

   StackLimit:        00151000

 

By running the program under debugger we can see that the stack has reached third last page. If you continue ‘g’ the program would run and consume the rest of the space onto the stack. Once it consumes the second last page as well and tries to access the Last page the program would raise an access violation exception since the last page is just reserved and not committed. At this point the program would be terminated. As you can see the thread gets one page less than what was reserved for stack since the last page is never committed.

 0:000> g

(1284.96c): Access violation - code c0000005 (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

eax=004720d0 ebx=7ffd9000 ecx=00000001 edx=776a6194 esi=00000000 edi=00000000

eip=00f01029 esp=00150ef0 ebp=00151218 iopl=0         nv up ei pl nz na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206

ThreadStack!RecurseFunction+0x9:

00f01029 e8d7ffffff      call    ThreadStack!ILT+0(?RecurseFunctionYAHXZ) (00f01005)

]]> User Mode program access kernel mode address https://docs.microsoft.com/archive/blogs/satyem/user-mode-program-access-kernel-mode-address Mon, 13 Aug 2012 20:50:00 GMT https://blogs.msdn.microsoft.com/satyem/2012/08/13/user-mode-program-access-kernel-mode-address/ What happens when a user mode program access the kernel mode address. The access fault happens, let's see how does the flow go in such scenario..

Actually all pages have a protection attribute that tells whether the page is owned by kernel or user. !pte shows that as K or U flag.

Now when CPU tries to access any page, it checks what privilege level is it running into. How is that checked? That it checks using code segment registers CPL (Current Privilege level value). you can always check the Privelege level the CPU is running into from cs register.

//Cs in Kernel mode . check that p/l value is 0. That means ring 0
kd> dg cs
                                                    P Si Gr Pr Lo
Sel        Base              Limit          Type    l ze an es ng Flags
---- ----------------- ----------------- ---------- - -- -- -- -- --------
0010 00000000`00000000 00000000`00000000 Code RE Ac 0 Nb By P  Lo 0000029b

//Cs for user mode instruction. check that p/l value is 3. That means ring 3
kd> dg cs
                                                    P Si Gr Pr Lo
Sel        Base              Limit          Type    l ze an es ng Flags
---- ----------------- ----------------- ---------- - -- -- -- -- --------
0033 00000000`00000000 00000000`00000000 Code RE Ac 3 Nb By P  Lo 000002fb

 For any memory address access, the Pvivilege level from CS and page protection is compared and if user mode tries to access any kernel mode address, cpu traps. MMAccessFult is the trap handler for such traps.

]]> Network connectivity issues diagnosis step by step - Part II. https://docs.microsoft.com/archive/blogs/satyem/network-connectivity-issues-diagnosis-step-by-step-part-ii Fri, 23 Dec 2011 15:13:00 GMT https://blogs.msdn.microsoft.com/satyem/2011/12/23/network-connectivity-issues-diagnosis-step-by-step-part-ii/ In the previous post, we discussed how to make sure if Windows Firewall really dropped incoming packets. If the machine is domain joined then group policies might not allow you to turn off firewall. In that case logging or creating inbound rules should be of help to determine the packet drop by WF. There is one other, some what less recommended, way to turn off firewall if policies don't allow to turn it off from Firewall management snapin and that is turning off the BFE service. Its BFE which creates and manages all the firewall filters and turning BFE off removes the firewall filter. Keep in mind that turning off BFE will stop a few other dependent services as well so when you are done with your experiments you should turn on the those dependent services also with BFE.

That's all for windows Firewall. If there are  third party firewalls on your system, they could also be the one causing packets drop. Each third party firewall has different configurations and troubleshooting, about which I can't comment much. However vista onwards most thirdparty firewall use BFE only, so you can see their filters and drop events in the BFE/WFP traces. Look out the command help of "netsh wfp capture" to learn about WFP tracing commands. These traces are  little  bit complex as they deal at filter level. Usually filter description gives some information about the filters source.This trace can be huge since it consists of all the communication esatblsihed with machine and all the filters present in the machine.

WFP auditing can also be used for WFP event log traces. You can enable WFP auditing using auditpol.exe. Below  commands can be used to turn on and off WFP auditing. And the logs can  be checked from Security Event logs.

auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable

auditpol /set /subcategory:"Filtering Platform Connection" /success: disable /failure: disable

So firewall is mostly the reason for packet drops. But in some cases it could be IPSec also. IPSec mostly comes into picture if your machine is domain joined and group policies have pushed IPSec policies on the machine. Needless to say IPSec policies can be there on non-domain joined machine also if the Admin has created them locally, but I haven't seen much such cases. Also if there are no IPSec Policies on the machine, then IPSec is not involved in the communication irrespective of the IPSec/IKE service status(running /stopped).  

Using Netmon you can check if any IKE packets are there in the capture between the two machine, if they are present then IPSes negotiation can be there between two machines and you should turn your attention towards IPSec Policies. IPSec rules can be seen from Firewall control panel(Wf.Msc)-> Connection Security Rule.

If IPSec is being used, you should make sure the corresponding policies are present on both the machine(unless one machine acts as a  boundary machine). Again turning off BFE would disable IPSEC but that should be done on both the machine if you are  doing experiment. I would like again emphasize that BFE and other dependent services should be  turned on again once you are done with verification.  Ping utility comes often handy to verify the communication between machines. More than often ICMP packets are exempted in IPSEC policies by the admins, so ping can be helpful in verifying the connectivity and making sure if IPSEC  is  causing the problem.

There are also authentication issues while accessing shares but they are not related to connectivity between machines but rather to NTFS and SMB permissions.  

]]> Where is my exception handler code in the function disassembly? https://docs.microsoft.com/archive/blogs/satyem/where-is-my-exception-handler-code-in-the-function-disassembly Thu, 22 Dec 2011 14:52:00 GMT https://blogs.msdn.microsoft.com/satyem/2011/12/22/where-is-my-exception-handler-code-in-the-function-disassembly/ This post discusses how compiler actually stores the exception filters and exception handler in the stack required for exception handling mechanism provided by OS.  Have a look at the disassembly of following main function and observe that on issuing uf main in windbg,  the output doesn't show the code under __except block. So where are my exception filter function and excpetion handler.

int main()
{
 int i=5;
 __try
 {
 i = 5/(i-i);
 }
 __except(FilterFunction2(1))
 {
  printf("__Except block\n");
 }

 return 1;
}

0:000> uf main
DivideByZero!main [c:\program files\microsoft visual studio 10.0\vc\homework\dividebyzero.cpp @ 13]:
   13 01061040 55              push    ebp
   13 01061041 8bec            mov     ebp,esp
   13 01061043 6afe            push    0FFFFFFFEh
   13 01061045 6830af0701      push    offset DivideByZero!__rtc_tzz+0x104 (0107af30)
   13 0106104a 68a0120601      push    offset DivideByZero!_except_handler4 (010612a0)
   13 0106104f 64a100000000    mov     eax,dword ptr fs:[00000000h]
   13 01061055 50              push    eax
   13 01061056 83c4f4          add     esp,0FFFFFFF4h
   13 01061059 53              push    ebx
   13 0106105a 56              push    esi
   13 0106105b 57              push    edi
   13 0106105c a100c00701      mov     eax,dword ptr [DivideByZero!__security_cookie (0107c000)]
   13 01061061 3145f8          xor     dword ptr [ebp-8],eax
   13 01061064 33c5            xor     eax,ebp
   13 01061066 50              push    eax
   13 01061067 8d45f0          lea     eax,[ebp-10h]
   13 0106106a 64a300000000    mov     dword ptr fs:[00000000h],eax
   13 01061070 8965e8          mov     dword ptr [ebp-18h],esp
   14 01061073 c745e405000000  mov     dword ptr [ebp-1Ch],5
   15 0106107a c745fc00000000  mov     dword ptr [ebp-4],0
   17 01061081 8b4de4          mov     ecx,dword ptr [ebp-1Ch]
   17 01061084 2b4de4          sub     ecx,dword ptr [ebp-1Ch]
   17 01061087 b805000000      mov     eax,5
   17 0106108c 99              cdq
   17 0106108d f7f9            idiv    eax,ecx
   17 0106108f 8945e4          mov     dword ptr [ebp-1Ch],eax
   18 01061092 c745fcfeffffff  mov     dword ptr [ebp-4],0FFFFFFFEh
   18 01061099 eb22            jmp     DivideByZero!main+0x7d (010610bd)

DivideByZero!main+0x7d [c:\program files\microsoft visual studio 10.0\vc\homework\dividebyzero.cpp @ 24]:
   24 010610bd b801000000      mov     eax,1
   25 010610c2 8b4df0          mov     ecx,dword ptr [ebp-10h]
   25 010610c5 64890d00000000  mov     dword ptr fs:[0],ecx
   25 010610cc 59              pop     ecx
   25 010610cd 5f              pop     edi
   25 010610ce 5e              pop     esi
   25 010610cf 5b              pop     ebx
   25 010610d0 8be5            mov     esp,ebp
   25 010610d2 5d              pop     ebp
   25 010610d3 c3              ret

This code is compiled in VC, some of the below details might be different for different compilers.

Durig compilation if a function has exception handling blocks( __try and __except) in it, then compiler pushes an Extended Exception Registration Record to stack. One important thing here is that, for one function there will be only Extended Exception Resgistration Record pushed onto the stack, irrespective of number of __try block in the functions. Lets see what this record is:

0:000:x86> dt PEH4_EXCEPTION_REGISTRATION_RECORD -r1
DivideByZero!PEH4_EXCEPTION_REGISTRATION_RECORD
Ptr32    +0x000 SavedESP         : Ptr32 Void
   +0x004 ExceptionPointers : Ptr32 _EXCEPTION_POINTERS
      +0x000 ExceptionRecord  : Ptr32 _EXCEPTION_RECORD
      +0x004 ContextRecord    : Ptr32 _CONTEXT
   +0x008 SubRecord        : _EXCEPTION_REGISTRATION_RECORD
      +0x000 Next             : Ptr32 _EXCEPTION_REGISTRATION_RECORD
      +0x004 Handler          : Ptr32        _EXCEPTION_DISPOSITION
   +0x010 EncodedScopeTable : Uint4B
   +0x014 TryLevel         : Uint4B

TryLevel is used as an index to the ScopeTable array to fetch out the right __except block( since there may be more than one nested try blocks). If you see from the above disassembly TryLevel is   at ebp-4, hence [ebp-4] gets updated every time the compiler sees that a new try block is entered/exited. Now lets see where this record is pushed in the stack.

Below is the snip from start of main function:

   13 01061040 55              push    ebp
   13 01061041 8bec            mov     ebp,esp

//This is try level, this value would be changed when a try block is entered.
   13 01061043 6afe            push    0FFFFFFFEh

//This is the scope table we would talk about this in a moment.
   13 01061045 6830af0701      push    offset DivideByZero!__rtc_tzz+0x104 (0107af30)

//This is common windows handler function called on exceptions. This in turn call the exception FilterFunction defined for the function.
   13 0106104a 68a0120601      push    offset DivideByZero!_except_handler4 (010612a0)

//This is Next Field of SubRecord struct shown above

   13 0106104f 64a100000000    mov     eax,dword ptr fs:[00000000h]
   13 01061055 50              push    eax                                                                               

// Here would come other two members(SavedEsp and Exception POinters) of the record.

  13 01061056 83c4f4          add     esp,0FFFFFFF4h

For any exception raised, _except_handler4 function is invoked by OS and is passed the Exception Registration Record as a paremeter. This function subtracts an offset 8 (offset of SubRecord field) to  get the Extended Exception Registration record that was pushed on to stack.

In Extended exception registration record, Scope table contains the actual Exception Filter Function and exception handler. Now lets take a look at the Scope Table:

0:000> dt _EH4_SCOPETABLE
DivideByZero!_EH4_SCOPETABLE
   +0x000 GSCookieOffset   : Uint4B
   +0x004 GSCookieXOROffset : Uint4B
   +0x008 EHCookieOffset   : Uint4B
   +0x00c EHCookieXOROffset : Uint4B
   +0x010 ScopeRecord      : [1] _EH4_SCOPETABLE_RECORD

The ScopeRecord field is an array of _SCOPETABLE_RECORD which contains the Exception Filter Function and Exception Handler for each try block. Here TryLevel (discussed above) is used as an index to get the right Filter function and  handler for corresponding _try block. ScopeRecord is at offset 0x10 of this structure. The scope table is at 0x0107af30, lets dump out the Scope record. Since for above main function TryLevel is 0, the corresponding excpetion Filter function and handler would be at index 0. 

 
0:000> dd 0x0107af30+10  l4
0107af40  fffffffe 0106109b 010610a6 00000000


0:000> dt _EH4_SCOPETABLE_RECORD
DivideByZero!_EH4_SCOPETABLE_RECORD
   +0x000 EnclosingLevel   : Uint4B
   +0x004 FilterFunc       : Ptr32     long
   +0x008 u                : <unnamed-tag> 

 FilterFunc is at offset 4 let's see what  filter function is:

0:000> uf 0106109b
DivideByZero!main+0x5b [c:\program files\microsoft visual studio 10.0\vc\homework\dividebyzero.cpp @ 19]:
   19 0106109b 6a01            push    1
   19 0106109d e863ffffff      call    DivideByZero!ILT+0(?FilterFunction2YAHHZ) (01061005)
   19 010610a2 83c404          add     esp,4
   19 010610a5 c3              ret

As you can compare with the code in the very begining, this is the assembly for Exception Filter Function(i.e. the code inside the __except()).

Now lets see where is our Exception handler Code(i.e the code insie __except {}). _EH4_SCOPETABLE_RECORD.u contains the address of exception handler block. Lets dump this:

0:000> u 010610a6
DivideByZero!main+0x66 [c:\program files\microsoft visual studio 10.0\vc\homework\dividebyzero.cpp @ 19]:
010610a6 8b65e8          mov     esp,dword ptr [ebp-18h]
010610a9 68d87e0701      push    offset DivideByZero!std::_Iosb<int>::end+0x4 (01077ed8)
010610ae e84e000000      call    DivideByZero!printf (01061101)
010610b3 83c404          add     esp,4
010610b6 c745fcfeffffff  mov     dword ptr [ebp-4],0FFFFFFFEh
010610bd b801000000      mov     eax,1
010610c2 8b4df0          mov     ecx,dword ptr [ebp-10h]
010610c5 64890d00000000  mov     dword ptr fs:[0],ecx
0:000> u
DivideByZero!main+0x8c [c:\program files\microsoft visual studio 10.0\vc\homework\dividebyzero.cpp @ 25]:
010610cc 59              pop     ecx
010610cd 5f              pop     edi
010610ce 5e              pop     esi
010610cf 5b              pop     ebx
010610d0 8be5            mov     esp,ebp
010610d2 5d              pop     ebp

Again if you compare, 010610a6 is the start address of code lines inside __except {} block.


 

]]> Windbg loops around First chance and Second chance exceptions https://docs.microsoft.com/archive/blogs/satyem/windbg-loops-around-first-chance-and-second-chance-exceptions Thu, 22 Dec 2011 14:50:00 GMT https://blogs.msdn.microsoft.com/satyem/2011/12/22/windbg-loops-around-first-chance-and-second-chance-exceptions/ My program causes an exception and debugger catches it, but the debugger is stuck in loop of first chance and second chance exception. Why isn't it get out of the loop and terminates the program if the exception is not handled?

A snip from debugger output

(2724.2708): Integer divide-by-zero - code c0000094 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
DivideByZero!main+0x15:
013516b5 f7f9            idiv    eax,ecx
0:000:x86> g
(2724.2708): Integer divide-by-zero - code c0000094 (!!! second chance !!!)
DivideByZero!main+0x15:
013516b5 f7f9            idiv    eax,ecx
0:000:x86> g
(2724.2708): Integer divide-by-zero - code c0000094 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
DivideByZero!main+0x15:
013516b5 f7f9            idiv    eax,ecx
0:000:x86> g
(2724.2708): Integer divide-by-zero - code c0000094 (!!! second chance !!!)
DivideByZero!main+0x15:
013516b5 f7f9            idiv    eax,ecx

 

When the exception is raised, windows kernel looks if the debugger is attached to the process. If yes, the process is broken into the debugger with First chance exception message. Continuing with 'g' goes with exception unhandled and the process is again broken into the debugger with Second chance exception message. However after first chance exception if you continue with 'gh' instead of 'g', you will see a loop of First chance exception only and no second chance.

After second chance exception continuing with 'g' goes with exception handled, and the kernel resumes the process again from the instruction where exception happened. Which again leads to the First chance exception and the cycle goes on...

However if after Second chance exception you continue with 'gn' instead of 'g', the debugger goes with exception not handled and program is terminated. You won't see an exception loop.

 

 

 

 

]]> Network connectivity issues diagnosis step by step - Part I. https://docs.microsoft.com/archive/blogs/satyem/network-connectivity-issues-diagnosis-step-by-step-part-i Wed, 21 Dec 2011 15:15:00 GMT https://blogs.msdn.microsoft.com/satyem/2011/12/21/network-connectivity-issues-diagnosis-step-by-step-part-i/ Many a time we run into network problems between computers in home, offices, labs etc.  which sometimes are easy to diagnose and sometimes they are not. I have heard from customers multiple times that they are not able to access some share on the other machine or not able to connect Telnet to other machines etc. But they are not able to track where exactly the problem is and what it is?

This post discusses some diagnosis steps which would be useful to anyone doing network troubleshooting. The focus is majorly on the issues caused by firewalls or any other filters in the stack blocking the communications. They are very general steps which many people might already know about, however following these steps help narrow down the issue and track to the root cause. Let's take an example of two machines A and B, where A is not able to access some resources shared on B (say \\B\SharedFiles\).

Very first thing one should try checking is whether or not DNS is able to resolve remote machine name. To verify this try accessing the remote machine with  its IP and not with its name. If accessing with IP works that alarms you about DNS name resolution problem. There could be problems like stale DNS cache, duplicate name or any other issues with DNS. However if accessing with IP also doesn't work then further steps should be tried to narrow the issue further down. It's better to use IP address in further troubleshooting so that you don't mess up with any DNS issue again during investigation.

Now there could be multiple places where the connection setup could be failing like:

  1. The connection packet started from machine A could not leave the Machine A itself.
  2. The connection packet reached machine B but B never replied.

Any network traffic capture software(like netmon) can help you identify above points in your network setup.

Mostly the customers run into issue pointed out by number 2. However if its #1 then probable reasons could be Firewall outbound rules, or a misconfigured gateway on Machine A. Most of the firewall by default allow the outbound connections but you should double check the firewall outbound configuration in this case and make sure it is right.

If it is #2, i.e. in network capture software running on machine B, you can see an incoming packet on B from A but no outgoing packet from B to A, in this case the chances are that firewall or something else dropped the incoming packet. Network capture software usually sit at below layers on the stack so it reads the packets long before the packet reaches firewall and is dropped.

Now is the time to verify if the firewall really dropped the incoming packet. If you are not able to see any inbound rule in the firewall for the communication in question, you should create an inbound rule in firewall for the desired communication and then check if the connections succeeds. Different firewalls have different interfaces to create inbound rule. One thing you should remember while creating rules in Windows firewall is that you chose right profile in your inbound rule. Windows firewall has three profiles Public, Domain and Private and while creating rules you need to select profiles for which the rules should be applicable. If you are not sure about the profiles, for investigation purpose you can chose all profiles so that your new incoming rule is applicable to all profiles.

For troubleshooting sake you might also consider to turn off firewall and then try the connection. I have seen a few customers do a mistake while turning off Windows Firewall, instead off turning it off from windows firewall management console, they just stop the firewall service(net stop mpssvc). Note that stopping the service is not the right way to turn firewall off, you should go to firewall management console (Wf.msc) and then should turn firewall off from there for all the profiles. I should emphasize that if you are not sure about the firewall profiles, turn it off for all the three profiles.

Well if the creating an incoming firewall rule or turning the firewall off helps solves the issue, it was your firewall that dropped the packets. You can figure out the same thing by enabling firewall logging and peeking into the trace and check if it has a trace for the dropped packet of communication in question. This might be difficult if there are many connection established on the machine as the trace becomes large.

Till now I just talked about Windows firewall, there might be other third party firewall dropping the packets. Or there could be something else blocking the communication like IPSec. Let's discuss them in next post.....

 

 

 

 

 

]]>