OK, let's summarize what has been done so far...
Earlier, we ran the RogueKiller which produced a log showing you, among other things, two views of your disk's condition. First, your view:
--- User ---
[MBR] bef71944b3b5de032e277fa31ccfb751
[BSP] 5ddb2240a06dd04c2f16e27a394def14 : Windows 7 MBR Code
Partition table:
0 - [XXXXXX] NTFS [HIDDEN!] Offset (sectors): 63 | Size: 12888 Mo
1 - [ACTIVE] NTFS [VISIBLE] Offset (sectors): 25173855 | Size: 106 Mo
2 - [XXXXXX] NTFS [VISIBLE] Offset (sectors): 25382700 | Size: 147044 Mo
User = LL1 ... OK!
User != LL2 ... KO!
Which shows us three partitions, the system reserve partition marked "ACTIVE" which is what we want.
The next view is the system's view:
--- LL2 ---
[MBR] 4c3bcdad733249acf5ba0fa43870e420
[BSP] 5ddb2240a06dd04c2f16e27a394def14 : Windows 7 MBR Code
Partition table:
0 - [XXXXXX] NTFS [HIDDEN!] Offset (sectors): 63 | Size: 12888 Mo
1 - [XXXXXX] NTFS [VISIBLE] Offset (sectors): 25173855 | Size: 106 Mo
2 - [XXXXXX] NTFS [VISIBLE] Offset (sectors): 25382700 | Size: 147044 Mo
3 - [ACTIVE] NTFS [HIDDEN!] Offset (sectors): 312579760 | Size: 1 Mo
...which shows the infected partition, labeled #3 above, as "ACTIVE".
Kindly note, this view shows 4 entries numbered as 0 thru 3 while the user view shows only 3 entries numbered as 0 thru 2. Windows. as a boot procedure, sees this as follows:
0 = partition 1
1 = partition 2
2 = partition 3 and so on...
For our purposes, partition 4, marked as #3, the bad one, needs to go while partition 2, marked as #1, needs to be set to "Active"
Now, that was then...Fast forward to the present, after having run the several tools mentioned. and ideally, at that point, what we would have wanted to see is that the infected partition had the boot flag and hidden attribute removed, and replaced with having set partition table entry #1 as "ACTIVE".
We ran a couple tools to address this infection, which seemed to have no effect. With your last posting, we find that things aren't as we thought they should be. To address THAT, we should look over what has been done to find a suspect which would answer the question, "how did this come about".
First suspect was aswMBR, which you said did nothing when you tried to execute it...aswMBR by itself, would not have been expected to re-set any boot flags or remove any infected partition without intervention, so we can eliminate that one.
Next up was BitDefender's automated removal tool which also did nothing when you tried to execute it. However, that one is purported to have the affect that you've described but with your earlier report that it too did nothing upon your execution attempt, then we can eliminate that one as well.
Next up was TDSSKiller. Here I think we have a winner with repect to what you've reported. This seems what is behind the present situation. An excerpt from the log seems to prove this:
15:59:50.0480 3188 \Device\Harddisk0\DR0 ( Rootkit.Boot.SST.b ) - infected
15:59:50.0480 3188 \Device\Harddisk0\DR0 - detected Rootkit.Boot.SST.b (0)
15:59:50.0558 3188 \Device\Harddisk0\DR0 ( TDSS File System ) - warning
15:59:50.0558 3188 \Device\Harddisk0\DR0 - detected TDSS File System (1)
15:59:50.0620 3188 Boot (0x1200) (4ae9670f027d0a89e0c7489090193fcf) \Device\Harddisk0\DR0\Partition0
15:59:50.0636 3188 \Device\Harddisk0\DR0\Partition0 - ok
15:59:50.0652 3188 Boot (0x1200) (9d87a2e1b9d5058b8bf2c0389474ae0b) \Device\Harddisk0\DR0\Partition1
15:59:50.0652 3188 \Device\Harddisk0\DR0\Partition1 - ok
15:59:50.0652 3188 ============================================================
15:59:50.0652 3188 Scan finished
15:59:50.0652 3188 ============================================================
15:59:50.0683 1920 Detected object count: 2
15:59:50.0683 1920 Actual detected object count: 2
16:00:27.0141 1920 \Device\Harddisk0\DR0 ( Rootkit.Boot.SST.b ) - will be cured on reboot
16:00:27.0141 1920 \Device\Harddisk0\DR0 - ok
16:00:27.0141 1920 \Device\Harddisk0\DR0 ( Rootkit.Boot.SST.b ) - User select action: Cure
...This seems also to account for the fact that your Windows Disk Management screenshot appeared to show us that it did not see this infection. Having taken the screenshot AFTER we ran TDSSKiller, if what I believe happened, actually DID happen, then things seem to be as they ought.
Now, let's see if we can prove this. While I assume you are still booted into the linux system view (GParted), Please answer these few questions:
1. Does the 1 MB partition have a Boot label under flags collumn?
2. Does the 1 MB partition say "unallocated" under "Partition" and "File System" columns? Is it greyed out?
...and upon your next reply, please be sure to tell me whether or not you are still booted into GParted or if you have indeed tried booting back into Windows yet. Rather than assuming you posted your previous comment from another computer, it's best I ask first before you will have need to reboot back and forth using GParted. Your answer may prove that we need only to use Windows Disk Management at this point, rather than GParted.