Have you tried installing the latest intel drivers? I've heard from other Intel users that this fixes the problem.

Have you tried installing the latest intel drivers? I've heard from other Intel users that this fixes the problem.

I'm pretty sure I'm running the latest drivers. I recently switched from Win7 64bit to Win7 32bit (the hiccups drove me nuts) and I made sure I installed the latest drivers from Intel's site. It's pretty much standard operating procedure for me to make sure I have the latest drivers for everything when I have issues with certain software or games, anyways. I'll take a second look, just in case there were newer drivers released in the past month or so.

Any updates?

I've this problem too (using intel 965 graphic card and win7). However it works fine under ubuntu 9.10 and i think any other linux distribution.

I apologize for not responding earlier, but I do have some updates. Just got an optional Windows update for the Intel 965 Express maybe a week ago. According to the update info, it's the drivers released in Sept of 2009, which I believe I already had installed, but I installed the Windows update just to be sure. No luck.

I'm not surprised to see that Blender runs fine under Linux. It has to be an issue with Intel's drivers... right? :-)

Closed a duplicate:
https://projects.blender.org/tracker/index.php?group_id=9&atid=498

I am having the same issue on a Lenovo laptop with the Mobile 965 Express. The crash occurs in ig4icd32.dll, so it seems to be an OpenGL issue. Lenovo provides custom drivers for this chipset, and I'm using the latest version from their website (Version 6.14.10.5218, Release Date: 2010/03/31, http://www-307.ibm.com/pc/support/site.wss/MIGR-67838.html).

I have the same problem with the June 1st Build (and all previous builds)

I have the same problem. I am using todays SVN, revision 30043. My system is Linux 64 bit with an ATI Radeon HD4800 graphics card. I get a "Segmentation fault" when I open the User Preferences from the file menu but not if I use the "CTRL ALT U" short cut. I have not had the issue for more then a month or two. I can fire up the old debugger and step through the code if you want me to.

I found a work around on my two computers.
Both computers have two different SIS internal GPU's.
Com 1: winxp: SIS 661
Com 2: win 7: SIS 672

Download the drivers for win98_ME.
Place the sisgl.dll in the blender directory.
On win 7 you may need to rename the "sisgl.dll" to "sisglv.dll".

New windows work fine on both computers after this.

Though LetterRip said it could be making blender switch to software opengl or d3d opengl emulation, not the sisgl.dll.

I also have a similar problem.
To me it seems related to the accessing the location of the user settings. I've installed by "Run as admin" and then "Run as admin" when launching blender. When selecting User Preferences, it crashes with no additional text in the console window.

Blender 2.53.0, r'30581'
Win7 32 bit
Nvidia Quadro FX 580 (latest drivers)
Intel Xeon W3520 @ 2.67Ghz
8GB RAM

UPDATE to my previous post:

To clarify, the problem with user preferences in on a machine joined to an Active Directory domain. I installed 2.53 under a regular user account, but ran the Windows installer .exe using "Run as admin". Then when I run Blender using "run as admin" I still get the errors, user preferences crashes Blender with no error messages.

I have another machine where I installed 2.53 with default settings using as admin account (no active directory) and user Preferences is working properly. This machine is an Alienware m15x laptop:
Intel Core2 X9000 2.6 GHz CPU
Nvidia GeForce 8800 M GTX
4 GB RAM

Users experiencing crash with user preferences opened, are you also experiencing problems when rendering to new window, ripping an area to a new window or duplicating the window? I think this is a driver problem.

For the first two, you can for now ensure you don't create a new window. User preferences you can see also by changing for instance the 3dview to user preferences, instead of using the top menu or default ctrl-alt-u. If rendering to new window: don't do that, instead render either fullscreen or to image editor.

Closed duplicate: https://projects.blender.org/tracker/index.php?func=detail&aid=23603&group_id=9&atid=498

Moving the report to our todo on the wiki. This and other opengl related issues on Windows will be moved there for aspiring developers to choose from.

http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Install-OS/OpenGL#UI_corruption

Marked duplicate: https://projects.blender.org/tracker/index.php?func=detail&aid=23953&group_id=9&atid=498

Marked duplicate: https://projects.blender.org/tracker/index.php?func=detail&aid=23959&group_id=9&atid=498

Closed duplicate: https://projects.blender.org/tracker/index.php?func=detail&aid=24242&group_id=9&atid=498

Closing duplicate https://projects.blender.org/tracker/index.php?func=detail&aid=24530&group_id=9&atid=498

◀ Merged tasks: T38790.

Odd this is closed since in 2.69 it still happens.

WORKAROUND:
Click the "Editor Type" button of your 3D View area, then select "User Preferences".

SO: What does "File / User Preferences" do that "Editor Type / User Preferences" does not so?

If the dialog works invoked from one code path but crashes from another, then is it really a driver bug?

@Jesse Chisholm (jessechisholm), the difference is that File / User preferences opens a new window, whereas changing editor in any existing editor does not.

You probably won't be able to create new windows with the running Blender instance either. Try rendering to a new window, or duplicate an editor (hold shift while LMB-dragging an editor grip corner). If you get a crash, then it is very likely your driver problem.

@Nathan Letwory (jesterking), I am not asking for a workaround, I have one of those.

I am reporting that a bug that crashes Blender has not gone away.

And, I suppose, I am suggesting that "File "User Preferences" should be changed to do things the way that does not cause the crash.

re: likely your driver problem
I accept that some drivers have problems.
I accept that Blender developers can't be expected to fix a bug in a driver.

But Blender should not leave code in that is known to trigger a crash, when it also has code that accomplishes (from a user's perspective) exactly the same goal and does NOT trigger a crash.

Yes, documenting various workarounds is good and necessary but insufficient for declaring a crash to be "not a problem".

@Jesse Chisholm (jessechisholm). In this specific case there's not much we can do about it, because on machines with properly behaving drivers creating new windows works as expected. This is exactly where for this specific case the current workaround is the only solution we can provide. Stating this is a workaround means we understand there is a problem.

I disagree that creating windows should be disabled because a driver does misbehave, whereas with the vast majority of drivers this feature works as expected and intended.

If you really want this issue fixed, a bug report should be filed with the party responsible for the driver. Until the author releases a driver with the necessary fix we'll keep on pointing to the known workarounds for this issue.

An effort could be done to make sure the issue doesn't crash entire blender, but for that a developer needs to be found, who can write code to do that. Perhaps you could have a go at finding a mechanism to handle that?