Are you sure it was not your little brother? I will give you one good advice, saved my neck a few times already: Get the program: Norton GoBack http://www.norton.com/ho...ecovery/ngb40/index.html Then: Go for Zonealarm Security suite or Panda Security Suite. Hope this help Bulli ;)

You must go to a Professional Technician for Help, for to see your PC and to fix it. If you make anything by your Own, i think that will enlarge your Problems. In the past i had the same problem and a Good Technician that i had, fix my Problems to my PC. George K.

K!!! This is you >>> :cry: There's a black cloud following you around. Make sure that whatever virus scanner you use is scanning the boot sector too. Otherwise, you can keep reinstalling everything and still be infected. If you start from scratch, delete all partitions and reformat the disk. Make sure that your backup files are not infected. If you created the backup files, deep scan them to make sure you are reinfecting yourself. Any external drives attached to your network should be scanned too. You can save yourself a lot of grief if you make a disk image after you perform a new installation. In the future, when you need to reinstall from scratch, this will save you hours or days. BTW, any remote connections also increase your exposure to virii. Last thought... if you know for sure that you are infected, then make sure you don't email your buddies. That exposes them too. Pretty soon you won't have any buddies left!

I'm using WinXP and have never been asked to set a permission for this file: <Windows Root>\\System32\\Ntoskrnl.exe. You pose an interesting question, since it a file that is targeted by virii. Fortunately, MS made a patch for this problem. The trick is this: When you reinstalled Windows, you should have updated service pack 2 from a CD and installed your antivirus software BEFORE connecting to the internet. Once connected, the first stop should be to MS updates, to get all of the security updates. Otherwise, you run the risk of becoming re-infected... even with a brand new installation. Description: Kernel initialization involves initialization of kernel modules and device drivers by NTOSKERNEL.EXE based on system registry entries. The CurrentControlSet and CloneControlSet registry areas are saved. A driver can report the following errors to the kernel. Ignore - No error is displayed. Normal - Booting continues with error displayed. Severe - The LastKnownGood configuration is used to boot. Critical - Booting fails if LastKnownGood configuration is being used to boot. Exact problem: The interrupt 06h (#UD) handler in NTOSKRNL.EXE contains a branch of code for quickly handling C4h/C4h machine code byte sequences according to the control word specified in the two bytes that follow, when the sequence occurs in Virtual-8086 mode (bit 17 of EFLAGS is set). If a control word value other than 4250h or 4350h (both used for fast file I/O) is given, the "bop" is passed off to another section of code in the process hosting the VDM. In NTVDM.EXE, this transition normally corresponds to returning from a call to NtVdmControl(0) (VdmpStartExecution), but in actuality, execution can be redirected anywhere, since the switch is just accomplished by swapping out context structures. The VDM TIB (arrived at by way of [[[[FFDFF124h]+44h]+1DCh]+98h] on Windows 2000, FS:[F18h] on Windows NT 4.0, Windows XP, and Windows Server 2003) is used to hold a copy of the V86-mode context in effect at the time the fault occurred (at offset +CD0h on NT4 and 2000, +2D8h for XP and 2003), then the context for resuming execution of the host code is retrieved (from offset +A04h on NT4 and 2000, +0Ch on XP and 2003) and loaded into the appropriate registers. As mentioned above, this context is contained in user memory but is not sanitized in any way by the #UD handler, so any process with or without a formally-initialized VDM can place arbitrary values in the host execution context and get the handler to IRETD to any CS:EIP, allowing kernel privileges to be retained while user-supplied code is executed. On any version of Windows, it is sufficient to modify the VDM TIB in a process with a properly initialized VDM (most easily done by code executing in a .COM file). For Windows NT 4.0, XP, and 2003, it is only necessary to set the pointer at offset F18h in the user-land TIB to reference a fake VDM TIB, then execute V86-mode code using NtContinue().