Per my testing of this setup (.NET 4.5 / IIS 7.5 with both windows authentication and forms authentication enabled), the following condition
(System.Web.HttpContext.Current.User.Identity is System.Security.Principal.WindowsIdentity)
is true (after the user successfully authenticates via Windows auth), which can be theoretically used to determine a way around this issue. You did not post any code, so I can't say for sure how you would solve your problem. Are you creating a custom forms authentication ticket?
It seems that Windows authentication now trumps the Forms authentication, and Request.IsAuthenticated == true even before the code creates the Forms authentication ticket! Very annoying, this caused problems for one of my customers when they decided to install .NET 4.5, after they had been working fine for several years by mixing both Windows and forms auth. For now (until a patch is ready, and customer has time to test and deploy it) the solution was to remove .NET 4.5 and re-install 4.0. If they really think they need 4.5 for something, they will use a diff machine.
For example, you could create a custom identity class with your own version of bool IsAuthenticated instead of relying solely on Request.IsAuthenticated (again, you didn't post code so I can only assume this is what you are doing). Then the solution involves checking whether the forms authentication ticket exists in the case where these two factors are true:
System.Web.HttpContext.Current.Request.IsAuthenticated && (System.Web.HttpContext.Current.User.Identity is System.Security.Principal.WindowsIdentity)
You can no longer rely solely on Request.IsAuthenticated because, technically, the request was authenticated when the user authenticated via Windows auth. (Whereas before, when mixing windows auth and forms auth, Request.IsAuthenticated was not true until the forms authentication ticket was created.)