I just spent two days tracking this problem down.
I received my new development machine with Windows7 x64 only a week ago. It all was just pefect – quad core CPU could compile the world in almost no time, and brand new Visual Studio 2010 was just as good as it gets. By the way, I am the Linux guy and prefer vim, automake and gcc any other IDE, so if I call Visual Studio perfect, it means something.
Neverthless, everything good has an end. Yesterday I tried to build bcp.exe tool I needed to dissect boost, and I faced very nasty and very unclear problem. I simply could not. Every time I started the build process, it would fail with the most weird message I ever seen:
\Microsoft was unexpected at this time
Well, I mentioned I am the Linux guy, but I am not a religious fanatic. I just thought that there was a problem of some sort in the boost’s build script and used another machine to build bcp.
Next day I became really concerned. I realized that I could not use “Visual Studio Prompt” from VS 2010 and VS 2008. Every time I tried to start them, they would have that message about unexpected microsoft on them; and environment variables were not set. So I could not build anything! Sadly, this was rather a major problem for me as we had quite a few makefile projects and not being able to set the correct environment for build process was that kind of present I could happily live without.
I spent next four hours to find that this or similar problem was already mentioned several times; but nobody offered a solution that would work and nobody explained what was causing that. Some said that Windows SDK installation could break the batch file vcvars32.bat; some thought there was a bug in the batch file itself. Strangely, it all worked perfectly on the the neighbor’s machine. I even compared the files and found no difference at all.
The solution came at the end of the day when all my hopes were gone. One guy mentioned that the problem was caused by the parentheses in vcvars32.bat:
@if not "%WindowsSdkDir%" == "" ( @set "PATH=%WindowsSdkDir%bin\NETFX 4.0 Tools;%WindowsSdkDir%bin;%PATH%" @set "INCLUDE=%WindowsSdkDir%include;%INCLUDE%" @set "LIB=%WindowsSdkDir%lib;%LIB%" )
He mentioned that as he found out, one of the directories where SDK was had braces in the name as well, and that broke the statement above completely as batch processor would find nested parentheses in the folder’s name and consider them as the end of the statement.
Needless to mention, may machine had some paths that had braces in them. C:\Program Files (x86). And, needless to mention, it is exactly where Visual Studio is installed. And it also exists in %PATH% environment variable.
By itself, it does not break the script. As I mentioned, it worked perfectly on the other machine which was the biological twin of my PC. But, what if one of the PATH’s members is encolsed in double quotes? (to check how your PATH looks like, type echo %PATH% in command prompt). I checked and that’s what I found:
c:\winutils;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem; C:\Windows\System32\WindowsPowerShell\v1.0\; c:\Program Files (x86)Microsoft SQL Server\100\Tools\Binn\; c:\Program Files\Microsoft SQL Server\100\Tools\Binn\; c:\Program Files\Microsoft SQL Server\100\DTS\Binn\; "C:\Program Files (x86)Microsoft Visual Studio 9.0\Common7\IDE\"; C:\Program Files (x86)Microsoft Team Foundation Server 2010 Power Tools\; C:\Program Files (x86)Microsoft Team Foundation Server 2010 Power Tools\Best Practices Analyzer\; c:\cygwin\bin
Bingo! I found that one entry of PATH was indeed enclosed in double quotes. And, not surprisingly, it had that nasty (x86) in it. It was pointing somewhere inside VS 2008 installation tree, so I think one of VS 2008 tools I have installed recently indeed screwed this up.
So, I simply removed those double quotes. Immediately after that, both VS 2010 and VS 2008 command prompts were fixed.
So, the fist thing you should do if you’re having the same problem: look at your %PATH% environment variable and check if anything is enclosed in double quotes.
Finding this just cost me two days of work, and I hope it it helps you sorting it out much faster.
thanks, this has helped a lot!
This post was a life saver. Thanks so much!
Delicious that you resolve this issue so succinctly, yet no reasonably reachable Microsoft resource answers the question at all.
Love it. Worked for me.
Thanks Bob,
Not sure if it is 100% Microsoft’s fault – anything can change environment variables.
But at least they could put some guidelines somewhere they could easily be found.
Perhaps, they are just ashamed of \Microsoft being unexpected
Thank you so much!! I was trying to build V8 on a machine I’d built V8 on a number of times in the past, and suddenly it breaks with this same error. So confusing… and so glad I googled it and got this page. Fixed my problem in minutes.
You saved me hours of digging. Thanks so much!
Thank you. This saved me a lot of time!
In my case it wasn’t the PATH but a LIBPATH set in another makefile before calling vcvars32.bat from within nmake within Cygwin. So check for quotes in LIBPATH too.
Anyway, your blog led me on the right track and saved me from desperation. Thanks a lot!
Thanks Rolf,
Will be keeping the libpath in mid too.
It took me two days of wanting to throw my computer out of window before I figured it out. I am glad my post hepls others.
Thanks a lot. My build scripts that worked on XP stopped working when I moved to Windows 7 today.
\CMake was unexpected at this time… The paths with spaces in them used to require the double quotes on XP. Yikes.
You saved my day !
Thank you.
Thanks for help, but in my case the problem was a little bit different.
In my Vcvars32.bat, there is a:
IF NOT EXIST “%VSINSTALLDIR%\VC\bin\cl.exe”
and for some reason the system failed at executing this check (even when I replaced VSINSTALLDIR with a real path). Commenting it out was wery helpful. Now everything works fine.
MY HERO!
very useful post
Hey vital
You’ve just saved me from hours trying to find out why Qt wouldn’t compile on my system (after it did find the last time).
Thanks dude!
I got bitten by this bug myself today while trying to compile something with nmake.
It’s really a limitation of cmd.exe itself, in that it can’t gracefully handle quotes and/or nested parentheses. By contrast, real command processors/shells (such as Bash or ksh) have no problems with quotes or parentheses, despite the scripting language being five years older than MS-DOS itself. So it really is Microsoft’s fault for not writing a more capable command interpreter/language.
It’s such a shame that MS still ships an awful yet vital piece of software with their latest versions of Windows.
Thanks!!
I keep finding ridiculous that Microsoft teams miss this stuff and we have to resort to community solutions.
Thanks !!!
Thank you very much!
Where can I send you a case of beer?
After struggling with this issue I quit drinking beer and switched to cognac
I’m glad this post helps others.
Amazing the walls are still standing around here. If I had not found this post within the next 5 minutes – something around her was going to get broken!
Microsoft’s stupid LogParser install put ” in the %PATH% variable!
You Rock
[...] http://www.blinnov.com/2010/06/04/microsoft-was-unexpected-at-this-time/en/ [...]
Thanks, you saved my life, man!
Thanks for the hint. Save me a lot of time and frustration too!
Unbelievable! I’ve been struggling with my development environment for DAYS, not being able to compile a darn thing and no online resource or help from my collegues could solve my problem. Then I found your post and it was a life saver. Thanks!
I guess you’ve saved me two days minus 5 minutes. Thanks a lot
After spending more than an hour on this and getting completely stumped, I decided to check online, and this was exactly the problem. Thanks a lot.
Thanks a lot!!! Very useful…
you. da. man.