debugger clobbers x64 alignment check flag EFLAGS.AC - by Sam Hocevar

Status : 

  External<br /><br />
		This item may be valid but belongs to an external system out of the direct control of this product team.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 657947 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 4/7/2011 6:51:18 AM
Access Restriction Public


The Visual Studio 2010 debugger clobbers the EFLAGS.AC CPU register flag when stepping into the code or resuming from a breakpoint. This makes it impossible to debug unaligned accesses.

The same happens with Visual Studio 2008.
Sign in to post a comment.
Posted by Microsoft on 4/14/2011 at 5:37 PM
It turns out that the flag gets cleared by Windows on any exception, including a breakpoint exception. If you try the code below, you can see that this applies to the second memory alignment exception as well.

#include <intrin.h>
#include <stdint.h>
int main(void)
__writeeflags(__readeflags() | 0x40000);
uint32_t foo[2] = { 1, 2 };
*((uint32_t *)((intptr_t)foo + 2)) = 3;
*((uint32_t *)((intptr_t)foo + 2)) = 3;

return foo[0];

This seems to be an intentional design by Windows, but you may want to file a connect bug against them anyway to see if this can be changed.

Visual Studio Debugger Team
Posted by Microsoft on 4/12/2011 at 1:17 AM
Thank you for attching the project and screenshots to help us reproduce this issue. Your issue has been routed to the appropriate VS development team for review. We will contact you if we require any additional information.
Posted by Sam Hocevar on 4/8/2011 at 9:15 AM
Maybe I should add that I am using Windows Vista Professional 64-bit with SP2, on an Intel Core2 Quad CPU Q9650 @ 3.00GHz, just in case the kernel might be involved in the issue.
Posted by Sam Hocevar on 4/8/2011 at 8:49 AM
I hope the attached files may prove useful. contains a minimal solution with a C++ project illustrating the problem.

unaligned-run-1.png is a screenshot of what happens after simply building and running the project. The executable crashes at line 13, when trying to execute the unaligned write operation.

unaligned-run-2.1.png is a screenshot of what happens when I run the project again, this time after putting a breakpoint at line 10, before the unaligned access. As expected, the EFL CPU flag has the 0x40000 bit set (red arrow).

unaligned-run-2.2.png is a screenshot of what happens when I step (using F10) to the next line. The EFL CPU flag lost its 0x40000 bit (red arrow again) for an unknown reason. After resuming (using F5), the executable no longer crashes at line 13.
Posted by Microsoft on 4/8/2011 at 4:55 AM
Thank you for reporting this issue.
But we were not able to reproduce it with the steps you provided. Could you please attach a project and some screenshots to help us investigate this issue?
Posted by Microsoft on 4/7/2011 at 7:14 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(