Today I was wondering why the GFlags option Stop on hung GUI appears in the Kernel Flags tab of the GFlags user interface. Does the kernel have a GUI which could hang?
So I tried to get some information from Microsoft, but MSDN just says:
The Stop on hung GUI flag appears in GFlags, but it has no effect on Windows.
So I wonder even more: a kernel flag for a kernel which has a GUI, but it's not the Windows kernel?
Although it seems not of practical use, can anyone explain this?
I also tried to get more information from WinDbg .hh !gflag, but it doesn't even give the statement that this won't work on Windows.
Kernel flag indicates flag takes effect immediately without requiring a reboot
Registry flag requires a reboot for the flags to take effect
the kernel does not have any gui that could hang.
the term windows doesnt mean kernel but the gui windows of the running application
check NtSetSystemInformation in your os to understand why 0x8 does not take effect
basically there are a few hardcoded magic numbers inside this api which tests each request for GlobalFlag changes and allows them or disallows them
in xp-sp3 this magic value is 0B2319BF0 so any flag that is < 0x10 will be disallowed
and stop on hung gui is 0x8 so it isnt effective and you cant set this from registry tab
so effectively no way of setting this flag
nt!NtSetSystemInformation+0x193:
80606009 8b03 mov eax,dword ptr [ebx] ds:0023:001285f8=00000008 <---- +shg
8060600b 25f09b31b2 and eax,0B2319BF0h < magic value in nt
80606010 8945a0 mov dword ptr [ebp-60h],eax ss:0010:fb569cf0=00000000
80606013 8b0d6c125580 mov ecx,dword ptr [nt!NtGlobalFlag (8055126c)] ds:0023:8055126c=00000000
80606019 81e10f64ce4d and ecx,4DCE640Fh <--another magic value both these magic values orred together
will be 0xffffffff covers the whole range of flags
8060601f 0bc1 or eax,ecx
80606021 8945a0 mov dword ptr [ebp-60h],eax ss:0010:fb569cf0=00000000
80606024 a36c125580 mov dword ptr [nt!NtGlobalFlag (8055126c)],eax ds:0023:8055126c=00000000
Related
It says that Jump out of range by 60 bytes
To solve my problem.
Conditional jumps in 8086 Assembly (and most assembly languages) have a limited distance they can jump. In other words, there's too much code between your jump instruction and the destination (in this case, 60 bytes too many). You didn't post your code so I can't tell you exactly what line to fix, but in general the solution is straightforward.
cmp ax,bx
jnz goHere
; more code is here than the conditional jump will allow
goHere:
; finish up what we were doing
ret
In order to fix the above code, we have to reverse the condition and JMP, since JMP isn't as limited as Jxx is.
cmp ax,bx
jz continue:
jmp goHere
continue:
; finish up what we were doing
ret
goHere:
; now we can get here even though we have too much code for a conditional jump
jmp continue ;this will also have enough range to go there.
There's several ways to re-arrange your code to allow conditional jumps to work as intended, and still get the desired outcome. This is just one technique for it.
Summary:
I've configured a GPIO as an interrupt. I can see from all of the registers that it appears to be triggering, but my interrupt routine is never called.
Details:
I'm using a Nucleo F446 board, and the documentation specifies that PC13 should be the input for the push button. I'd like to trigger an interrupt when this happens (I know that this isn't the best way to handle a button; I was having trouble with a more complex system and reduced it to this simplified example). I'm doing this on bare metal and not using any existing libraries.
PC13 comes into EXTI13:
I see that this is interrupt #40 from the microcontroller reference manual:
I'm configuring the microcontroller as follows (using pseudo-c here for simplicity):
Enable clocks for GPIOC block, SYSCFG
RCC_AHB1ENR |= GPIOC_EN
RCC_APB2EN |= SYSCFG_EN
Enable external interrupts for GPIO C13 (it is by default an input)
SYSCFG_EXTICR4 |= (PCx << 4)
Set pin 13 of the interrupt mask, event mask, and rising trigger selection registers:
EXTI_IMR |= 1 << 13
EXTI_EMR |= 1 << 13
EXTI_RTSR |= 1 << 13
Enable IRQ 40
NVIC_ISER1 |= 1 << 8
Set up interrupt vector (here is a disassembly)
08000000 <_reset-0x124>:
...
80000e0: 08000621 .word 0x08000621
08000620 <exti15_10_handler>:
8000620: 4906 ldr r1, [pc, #24] ; (800063c <exti15_10_handler+0x1c>)
I have the main code in a loop printing a number of register values, which I will describe in a moment, to the serial port. I've implemented exti15_10_handler to turn on an LED and go into an infinite loop, so I should know when it is called, because it will also stop the printing. When I press and release the button, I see the following:
In GPIOC_IDR (the GPIO input register), I can see bit 13 change, which tells me the GPIO block is working.
In EXTI_PR (external interrupt pending), I see the value of bit 13 switch from 0 to 1 and stays there.
In NVIC_ISPR1 (interrupt set pending), bit 8 (corresponding to interrupt 40) switches from 0 to 1 and stays there.
However, NVIC_IABR0 (interrupt active bit register) does not change.
Interrupt is not called, as I see no change in the LED and the board does not hang.
I'm sure I'm forgetting to enable something, but after dredging through the reference manuals and a bunch of code examples, I'm just not seeing it. I did try the following:
asm volatile ("cpsie i" : : : "memory");
To set the interrupt flag (which I think should have been on already). I'm curious if this looks familiar to anyone.
This is a pretty unsatisfying result. While looking at the disassembly of the interrupt vector table, I noticed:
8000000: 20020000 .word 0x20020000
8000004: 08000124 .word 0x08000124
8000008: 08000595 .word 0x08000595
800000c: 08000595 .word 0x08000595
The second entry is supposed to be my reset vector
.section .interrupt_vector
.word _estack // Stack pointer
.word _reset
Although _reset is a thumb function, it is not encoded with the LSB set to indicate that. If I change the line to:
.word _reset + 1
...or put .thumb_func immediate before my reset handler in my startup code, it works correctly every time.
I coded a C program in vistual studio and complied in 64 bit
#include<stdio.h>
int main()
{
printf("Hello World!!!\n");
return 0;
}
And I use IDA freeware to disassembly it, I didn't see main but follow
public start
start proc near
jmp start_0
start endp
after I clicked start_0, The following code showed
start_0 proc near
arg_0= qword ptr 8
mov [rsp+arg_0], rcx
sub rsp, 28h
call sub_7FF691D52000
add rsp, 28h
retn
start_0 endp
obviously not main too, and I also didn't find main in function table and also I found a answer in the internet
Windows --> Exports
But I only saw start function in the result
how to find main? where to find it? or do I need to set somethings?
To find functions by name used in sources, you can load your programs symbols in IDA (pdb file).
Without symbols you can open strings view, find there "Hello World!!!\n" string and double-click it.
IDA View opens with the cursor on the strings address. Open XREFS window (Ctrl+X) of this string. It should contain only one entry - your printf function.
Double-click this entry and you will land on printf in your main.
I'm currently learning the workings of an operating system and would like to verify if my knowledge is correct on the steps taken during an interrupt. Trying to relate to something very familiar, here's what I think would happen when I press Alt+Tab to switch programs:
An interrupt is generated by the hardware (keyboard): intr flag of the CPU is set via system bus from keyboard controller
CPU saves the current process state to the PCB to pass control to the interrupt (is kernel mode entered here?)
CPU reads interrupt to index the interrupt service routine via the interrupt vector stored in memory
The interrupt service routine (along with the interrupt details such as which keys got pressed) is processed (at which point I assume user sees the program being switched)
The interrupt is complete (mode bit set back to 1 indicating user mode now?), PCB of the interrupted process gets restored and resumes running.
Are there steps that I'm missing or did not describe correctly?
There are many many factors here that you need to take in to consideration. For example:
- Is the keyboard on the ISA bus and is of an PC/AT style keyboard?
- If so, is the PIC (programmable Interrupt Controller) involved?
- Is the keyboard a USB keyboard device?
- Is the interrupt an older style PIC, newer style APIC, or a latest style MSI interrupt?
There are many things to consider. However, to try to explain what probably happens, I will assume you have an AT style keyboard attached to the keyboard controller port (PS2 style maybe), you have an older style PIC, and a simplified single- or multi-tasking system.
What could happen when the user presses the Alt key and then the Tab key:
- The CPU is interrupted (hence the name) by the PIC
- The CPU "jumps" to the interrupt request routine (IVT, exception, whatever)
- The routine reads from the keyboard. A single byte is read which happens
to be (part of) the make code for the alt key.
- the routine then places this make code in some sort of input buffer the
operating system has set up for it, whether it be part of the OS or part
of the keyboard driver.
- the interrupt is acknowledged via the PIC (this step can and usually is
before the previous step)
- the routine gives up the CPU (iret instruction)
The process is repeated three more times (assuming a make code and a break code are single byte codes. They can be multiple-byte codes). An interrupt is created on a make and a break key. A make key is when a key is pressed. A break key is when a key is released. i.e:
- make (Alt Down)
- make (Tab Down)
- break (Tab Up)
- break (Alt Up)
You see, there are four interrupts that take place (again assuming single-byte codes), four times the interrupt routine is called, and four times the CPU is interrupted to handle the key press(es) and release(es).
As for the task switching, via an ALT-TAB key combination, this is usually not done within the interrupt handler. The OS will see the Make (or Break) key of the Tab, it will check the status of the shift state (which should include the Alt key) and go from there.
It the keyboard is a USB style keyboard, then you have a totally different process of events. The USB keyboard does not interrupt the CPU as shown above. The keyboard has an Interrupt Pipe that periodically checks to see if there is a key make or break sequence. The OS will give up a time slice to the USB driver, just enough time to check this Interrupt Pipe. However, please note that an Interrupt (PIC, MSI, or other) is not triggered for USB keyboards, unless the USB driver specifies an interrupt should happen at end of frame. Note though that this interrupt is not fired because of the key press (or release), it is triggered because of the end of frame of the USB has taken place.
There is a lot that takes place because of a simple key press and release. I would study on what style of keyboard you wish to program for, what style of interrupt controller, CPU, etc., and go from there.
If you wish, I wrote a series of books on this subject where I explain what happens for both an ISA style keyboard and a USB style keyboard. It has been a very enjoyable hobby and I hope you find the same joy in yours.
With Cheat Engine it is possible to watch a particular address and keep track of what has accessed a particular memory address. I was wondering if this can be done too with OllyDbg or IDA. I could not find anything that would do that.
You can use hardware log breakpoint for that purpose.
Go to the address you want to monitor in the dump window (e.g here, I want to monitor 0xCB7008):
Press CTRL+F5 on the chosen address in the dump window (or right click and `breakpoint > hardware log):
Set Break on to Access R/W
In Expressions enter once again the address in square brackets
Set Pause Program to never if you don't want to stop on each access.
Set Log values of expressions to Always
Note that the data size if not really important (1 byte will break for 2 or 4 bytes access).
Go to the log window (ALT+L), press CTRL+X to clear it, and run your program (F9).
In the log window: you should see all accesses to the memory (the leftmost column indicates the code address where the read/write happens):