I made my first leap into the Apple world yesterday with my shiny new iPod Touch. I messed around on it for 2 hours downloading some game applications and songs.
When I was ready to shut down for the night... I noticed some settings that would allow me to put restrictions on its use. I thought, "Great! Now I can lock my kids out of downloading whatever random application they go looking for, since this Touch is linked to my iTunes account; which is linked to my payment information."
So I turned on the restriction for installing apps; thinking it would only stop someone that was using my iTouch on a Wi-Fi network from installing applications from the App Store. I turned off my iPod and slept for the night.
The next day I fired up iTunes with my trusty Touch connected to the USB on my laptop. I downloaded one more app from iTunes and was going to sync with my Touch.
I clicked on the Applications tab in iTunes for my iPod Touch and all the controls were greyed out (disabled.)
It turns out you need to lift/remove the restriction on your iPod in order to enable iTunes to install an app on it too.
To enable/disable the restriction, navigate to:
Settings >> General >> Restrictions >> Installing Apps
EDIT: Make sure you sync your device after making the change... some have still had the option greyed out after making the change.
Annoying, but safe... and now you know...
2008-08-15
Windows Remote Desktop Silently Fails When Trying to Connect
I was trying to use Remote Desktop to connect to my work computer; which I'd done successfully a plethora of times in the past. But for some reason yesterday, it decided not to work. The Remote Desktop client provided by Microsoft usually gives me an error if it's an authentication issue, or someone else is already connected, etc... but in this particular case, I got nothing. The client disabled all buttons when I clicked "Connect, and a few seconds later re-enabled them without any notification why.
After determining that multiple people (both connected via VPN and on the local network at work) had the same results, we started trying to find out what was up. Rebooting the computer did not solve it.
After much pain and suffering, we discovered this message in the event viewer (several times):
\SystemRoot\System32\RDPDD.dll failed to load
Doing a search on the internet quickly (and thankfully) brought me to Brad Rutkowski's Blog which had an article about the \SystemRoot\System32\RDPDD.dll failed to load error.
The article suggests several fixes. I've only confirmed the "D" option which is a registry tweak that increases the size of the session image space. It worked like a champ and I'm now able to get back into my work machine from home.
The only things I remember doing recently were a slew of Windows Updates from around 13 August 2008 and I think I update the nVidia drivers a week or so before. (Incidentally I hadn't tried remoting in since those two updates were done.)
For convenience, I've repeated the registry tweak fix here:
Thanks Brad for providing that information!
Please tell us about your experiences with this problem...
After determining that multiple people (both connected via VPN and on the local network at work) had the same results, we started trying to find out what was up. Rebooting the computer did not solve it.
After much pain and suffering, we discovered this message in the event viewer (several times):
\SystemRoot\System32\RDPDD.dll failed to load
Doing a search on the internet quickly (and thankfully) brought me to Brad Rutkowski's Blog which had an article about the \SystemRoot\System32\RDPDD.dll failed to load error.
The article suggests several fixes. I've only confirmed the "D" option which is a registry tweak that increases the size of the session image space. It worked like a champ and I'm now able to get back into my work machine from home.
The only things I remember doing recently were a slew of Windows Updates from around 13 August 2008 and I think I update the nVidia drivers a week or so before. (Incidentally I hadn't tried remoting in since those two updates were done.)
For convenience, I've repeated the registry tweak fix here:
Please see the blog post on Brad's site for the rest of the options if this doesn't work for you.D) A solution found at http://forums.nvidia.com/index.php?showtopic=67147&hl=remote%20desktop&st=60 worked for me (and others.)
It's a registry fix that increases the size of the session image space. Add the following key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"SessionImageSize"=dword:00000020
Where 00000020 is hex for 32
In any case the event was a red herring and was just a generic error being bubbled up from Win32k.sys..
Thanks Brad for providing that information!
Please tell us about your experiences with this problem...
2008-08-12
Once Outlook 2003 Comes Up in Safe Mode it Keeps Coming Up in Safe Mode
I had a problem where, after using Remote Desktop to bring up my work computer, Outlook 2003 would appear as if in "Safe Mode" making it look quite dorky. I believe this to be caused by my Remote Desktop settings being set to 16-bit so things aren't so bogged down during the remote session. Closing Outlook and re-opening it didn't help.
Rebooting, as is often the case, resets things and makes them right again where it will come back up in Normal Mode, but that's not an acceptable solution when you have several other windows open and you're not ready to shut them all down to reboot just to fix Outlook dorkness.
What I found was that the problem had to do with the fact that I had a Windows Mobile device sometimes hooked up with my machine using ActiveSync. This causes another non-GUI instance of OUTLOOK.exe to be running in your task manager so it can keep things in sync.
When this is the case... closing down the GUI only closes down the one instane of Outlook, leaving the one the mobile device opened still running. This keeps Outlook from resetting it's mode the next time you launch the GUI.
The solution:
Open Task Manager by either right-clicking the taskbar and selecting "Task Manager"; or by hitting Ctrl-Alt-Delete and selecting the "Task Manager" button.
When in Task Manager, click the "Processes" tab and click the "Image Name" column header to sort them alphabetically (this will get all instances of Outlook together.) Highlight each instance, one-at-a-time, and click "End Process."
Once they're all cleared out, you'll be able to re-launch the Outlook GUI and have it appear in "Normal Mode" again, without requiring a reboot of the computer.
I hope this helps someone, and I'm not positive if it works on other versions of Outlook; but I'd have to imagine it does... please chime in with your comments if you have had similar situations; and/or know if this solution works for other versions of Outlook.
Rebooting, as is often the case, resets things and makes them right again where it will come back up in Normal Mode, but that's not an acceptable solution when you have several other windows open and you're not ready to shut them all down to reboot just to fix Outlook dorkness.
What I found was that the problem had to do with the fact that I had a Windows Mobile device sometimes hooked up with my machine using ActiveSync. This causes another non-GUI instance of OUTLOOK.exe to be running in your task manager so it can keep things in sync.
When this is the case... closing down the GUI only closes down the one instane of Outlook, leaving the one the mobile device opened still running. This keeps Outlook from resetting it's mode the next time you launch the GUI.
The solution:
Open Task Manager by either right-clicking the taskbar and selecting "Task Manager"; or by hitting Ctrl-Alt-Delete and selecting the "Task Manager" button.
When in Task Manager, click the "Processes" tab and click the "Image Name" column header to sort them alphabetically (this will get all instances of Outlook together.) Highlight each instance, one-at-a-time, and click "End Process."
Once they're all cleared out, you'll be able to re-launch the Outlook GUI and have it appear in "Normal Mode" again, without requiring a reboot of the computer.
I hope this helps someone, and I'm not positive if it works on other versions of Outlook; but I'd have to imagine it does... please chime in with your comments if you have had similar situations; and/or know if this solution works for other versions of Outlook.
2008-06-26
Would You Like To Buy Some Silicone Fan Mount Grommets?
First off... who on Earth came up with the name Grommet? Whoever it was, it's cool.
I bought an Antec computer case a while back and the 120mm fan on the back was mounted with these cool plastic looking things instead of the normal fat metal screws with threads so thick you can't easily screw them into the case without a power drill. The "plastic looking things" are, in fact, referred to by Antec as "Silicone Fan Grommets."
Needless to say, I was opting for the Grommets as I hate messing with those fat metal screws; and I just really like the word Grommet.
Luckily when my fan died, the hardware kit that came with my case contained 4 extra Grommets I used on the replacement. I also noticed an internal mounting spot for another 120mm fan to help extract heat from the hard drive bays. I decided I wanted to mount a fan there as well, but knew I'd have to have Grommets there or I'd be in big trouble trying to get the screws to mount in that area.
I decided to try Googling for them; but realized I had no clue what they were called. I started with the phrase: 'antec fan mount screws' (without quotes) in hopes of finding them as a "related item."
I quickly gave up and headed to the official Antec website. They have a "Spare Parts" link that will allow you to buy the not-so-easy-to-find parts. It was there (and thank heaven most items have images next to them) that I found the Grommets. I never would have found that name on my own.
Searching for Grommets on the search engines after I discovered their "official" name didn't turn up many other options for where to purchase them.
So if you're looking for them, I'd recommend Antec. When I purchased mine, they cost $6.45 for a set of 4, but the shipping was free; so that was nice. If any of you out there know of more places to purchase Grommets, please leave a comment with a link so we can all be enlightened on where to find these very useful fan mounting tools.
You know what they say, "by small things shall great things come to pass." Since these are meant to help noise reduction with the fans, I'd consider that a great thing.
Happy grommeting!
I bought an Antec computer case a while back and the 120mm fan on the back was mounted with these cool plastic looking things instead of the normal fat metal screws with threads so thick you can't easily screw them into the case without a power drill. The "plastic looking things" are, in fact, referred to by Antec as "Silicone Fan Grommets."
Needless to say, I was opting for the Grommets as I hate messing with those fat metal screws; and I just really like the word Grommet.
Luckily when my fan died, the hardware kit that came with my case contained 4 extra Grommets I used on the replacement. I also noticed an internal mounting spot for another 120mm fan to help extract heat from the hard drive bays. I decided I wanted to mount a fan there as well, but knew I'd have to have Grommets there or I'd be in big trouble trying to get the screws to mount in that area.
I decided to try Googling for them; but realized I had no clue what they were called. I started with the phrase: 'antec fan mount screws' (without quotes) in hopes of finding them as a "related item."
I quickly gave up and headed to the official Antec website. They have a "Spare Parts" link that will allow you to buy the not-so-easy-to-find parts. It was there (and thank heaven most items have images next to them) that I found the Grommets. I never would have found that name on my own.
Searching for Grommets on the search engines after I discovered their "official" name didn't turn up many other options for where to purchase them.
So if you're looking for them, I'd recommend Antec. When I purchased mine, they cost $6.45 for a set of 4, but the shipping was free; so that was nice. If any of you out there know of more places to purchase Grommets, please leave a comment with a link so we can all be enlightened on where to find these very useful fan mounting tools.
You know what they say, "by small things shall great things come to pass." Since these are meant to help noise reduction with the fans, I'd consider that a great thing.
Happy grommeting!
2008-05-14
PHP fails to load MySQL Extensions claiming "The specified module could not be found" on Windows
I ran into this issue tonight after setting up Apache 2.2.8, PHP 5.2.6 and MySQL 5.1 on Windows XP SP3. I installed Apache using their installer and then manually configured httpd.conf. I downloaded the non-installer zip version of PHP; extracted it, saved a copy of php-ini-recommended as php.ini and manually configured it.
I correctly set the PHPIniDir setting in httpd.conf and set the correct extension_dir. I confirmed so by bringing up a page with phpinfo() called and it was showing my other extensions loaded. I'd comment one out (like php_gd2.dll) then restart Apache and refresh the phpinfo() page. The gd information disappeared, so I knew the settings were correct.
After a bunch of searching, I finally found a newsgroup post that pointed me in the right direction. there is another dll called libmysql.dll that comes with PHP (but is in the root PHP folder, NOT the ext folder.)
Both php_mysql.dll and php_mysqli.dll depend on this DLL. The fix was to copy this file to the WINDOWS directory. Once I did that, I restarted Apache and refreshed my phpinfo() page. There they were. Huzzah!
In my searching it seems people may run into this issue because of a few different things; so I'm publishing what I think is a good plan of attack for discovering what might be the problem when you can't get the MySQL extensions to load in PHP:
I correctly set the PHPIniDir setting in httpd.conf and set the correct extension_dir. I confirmed so by bringing up a page with phpinfo() called and it was showing my other extensions loaded. I'd comment one out (like php_gd2.dll) then restart Apache and refresh the phpinfo() page. The gd information disappeared, so I knew the settings were correct.
After a bunch of searching, I finally found a newsgroup post that pointed me in the right direction. there is another dll called libmysql.dll that comes with PHP (but is in the root PHP folder, NOT the ext folder.)
Both php_mysql.dll and php_mysqli.dll depend on this DLL. The fix was to copy this file to the WINDOWS directory. Once I did that, I restarted Apache and refreshed my phpinfo() page. There they were. Huzzah!
In my searching it seems people may run into this issue because of a few different things; so I'm publishing what I think is a good plan of attack for discovering what might be the problem when you can't get the MySQL extensions to load in PHP:
- Confirm the extension_dir setting in php.ini is set correctly (trailing slash is required on Windows; I'm not sure about other operating systems. Example: C:/php/ext/)
- Confirm the files exist in your extensions directory and are spelled correctly.
- Ensure libmysql.dll is copied from the root PHP directory to the Windows directory. This is extremely important if you've upgraded PHP as well and have an older libmysql.dll in the Windows directory that may not work with the newer PHP code. Make sure the current PHP version's libmysql.dll is copied to the Windows directory.
If you have discovered anything I may have missed that would help others that also run into this issue; please leave your feedback here.
2008-03-31
Apache HTTP Server Config - Forbidden Error After Configuring httpd.conf
I've seen many posts on many forums and newsgroups where people have run into problems getting Forbidden 403 errors after setting up Apache and modifying the httpd.conf file to their liking on their server.
Most have replied that the cause of the problem is that the directory in question doesn't have the right options set on it and they go into detail explaining that they need to add things like:
Options +FollowSymLinks
to their httpd.conf for that directory.
They're accurate, but their description isn't full enough to solve the problem. What I've found is that there are two things that need to be configured first off in httpd.conf to ensure success with your specific "DocumentRoot".
In the default httpd.conf file are two lines (with comments) that go hand-in-hand:
(using a default installation of Apache on Windows XP as an example.)
#
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "C:/Program Files/Apache Software Foundation/Apache2.2/htdocs"
... and the other section (contents excluded) as follows ...
#
# This should be changed to whatever you set DocumentRoot to.
#
...
In-between these two sections is a section that sets ALL directories to a "default" set of VERY restrictive features.
Options FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
The problem I've found (and I've made this mistake several times myself; so I'm documenting it here to hopefully help someone else fix the same mistake that causes the Forbidden message...) is that people change the DocumentRoot setting to where they want the default folder for serving up documents to be... but don't change the second section that matches the original DocumentRoot's path.
The reason the forbidden error happens is because that section inbetween restricts ALL directories, and the section after (that originally has the old DocumentRoot path) lifts the restrictions... but since it's still pointing to the old DocumentRoot and not the one you've changed to... it's lifted the restrictions on the wrong path; leaving your REAL DocumentRoot restricted and therefore causing the Forbidden message.
I hope this helps someone save hours of frustration trying to find out where to add the Overide +FollowSymLinks, etc... when it's already done for you in the original httpd.conf, you just need match the paths in that Directory section with your DocumentRoot setting.
NOTE: I'm not the ultimate guru on httpd.conf... there may be more secure ways to handle this and I'd love for someone to leave comments here on better ways. I just know this way works to get you up and running fast to solve the Forbidden problem.
Apache rocks. Happy HTTPing!
Most have replied that the cause of the problem is that the directory in question doesn't have the right options set on it and they go into detail explaining that they need to add things like:
Options +FollowSymLinks
to their httpd.conf for that directory.
They're accurate, but their description isn't full enough to solve the problem. What I've found is that there are two things that need to be configured first off in httpd.conf to ensure success with your specific "DocumentRoot".
In the default httpd.conf file are two lines (with comments) that go hand-in-hand:
(using a default installation of Apache on Windows XP as an example.)
#
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "C:/Program Files/Apache Software Foundation/Apache2.2/htdocs"
... and the other section (contents excluded) as follows ...
#
# This should be changed to whatever you set DocumentRoot to.
#
...
In-between these two sections is a section that sets ALL directories to a "default" set of VERY restrictive features.
Options FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
The problem I've found (and I've made this mistake several times myself; so I'm documenting it here to hopefully help someone else fix the same mistake that causes the Forbidden message...) is that people change the DocumentRoot setting to where they want the default folder for serving up documents to be... but don't change the second section that matches the original DocumentRoot's path.
The reason the forbidden error happens is because that section inbetween restricts ALL directories, and the section after (that originally has the old DocumentRoot path) lifts the restrictions... but since it's still pointing to the old DocumentRoot and not the one you've changed to... it's lifted the restrictions on the wrong path; leaving your REAL DocumentRoot restricted and therefore causing the Forbidden message.
I hope this helps someone save hours of frustration trying to find out where to add the Overide +FollowSymLinks, etc... when it's already done for you in the original httpd.conf, you just need match the paths in that Directory section with your DocumentRoot setting.
NOTE: I'm not the ultimate guru on httpd.conf... there may be more secure ways to handle this and I'd love for someone to leave comments here on better ways. I just know this way works to get you up and running fast to solve the Forbidden problem.
Apache rocks. Happy HTTPing!
2008-01-14
ATi Catalyst Display Driver Issue: "CRT invalid display type" on Windows XP
Catalyst Display Driver 7.7 and higher
When a digital panel is connected to a Radeon graphics card between Radeon models 9500 and HD2900 (including X300 through X1950) you will see many errors in the Windows event log listed as "CRT invalid display type"; with the source being "ati2mtag".
AMD/ATi has known about this issue since the end of August 2007 and has supposedly been investigating it. I don't know that they have discovered a fix yet as I just downloaded the newest drivers from last December and have these errors popping up in my own event viewer (hence my own Google chase.)
I figured I would try to save others some trouble. Click the link above to get updated information if/when it arrives. At the time of this posting, the article has been viewed 18227 times and only modified once, the day after the original post. I guess they haven't figured it out yet. :)
Their solution is to install Catalyst version 7.6; and they say it won't cause issues to the system or performance (though from my Googling, it sounds like many have had system hangs/random reboots/screen blankouts because of it.) Your mileage may vary. I haven't seen any reboots myself.
Please comment on your experiences with this issue and any better solutions (if any) you've found.
Subscribe to:
Posts (Atom)