Dave's Eclectic Ramblings

May

Remove Chameleon Debug Message

by Dave on May 20, 2010 · 0 comments

In recently updating my Dell 1525 Hackintosh to Snow Leopard 10.6.3, when installing Chameleon 2 RC3 (or RC4, for that matter), I noticed when booting that I’d get a quick flashing debug message stating, ‘efi_inject_get_devprop_string NULL trying stringdata‘. The message was fine, it didn’t make the install fail to boot or not work. Things operated exactly as they should, however, being the perfectionist, I didn’t want to see it. So, I set about trying to figure out what it meant and how to get rid of it. After much searching, there really wasn’t any one good — EASY — solution. . .

The Dell 1525, when loaded and configured correctly for Snow Leopard, doesn’t require any ‘device-properties’ string injection, which is great and makes things much easier when installing to this particular machine. Chameleon, being the excellent bootloader that it is, allows for this; and, many platforms require usage of it to work and operate correctly. However, when the Chameleon developers compiled up RC3 and RC4, they inadvertently left the debug message noted above being shown on boot regardless of whether or not you were booting verbose or quick and quiet. And, for the 1525, the message means nothing as the platform doesn’t require any injection, so it’s just completely benign debug output logging.

One solution to get rid of the message was to recompile Chameleon 2 RC3 or RC4, changing the ‘printf’ that displays this debug message all the time to a verbose logging message so that it only displayed when booting verbose. Well. . . Recompiling the whole bootloader was way more effort than I wanted to get into just to get rid of some cosmetic “blip” that was annoying when booting. Still, I wanted the message gone! So, I came up with the following fix. . . which seems to work fine for me, and should for any other Dell 1525 Hackintosh user out there that’s not using device injection (and, you shouldn’t need to on the 1525), but that is using Chameleon 2 RC3 or RC4.

So, a quick and dirty way of getting rid of the message. . .

Download and launch EFIStudio (Google it up and download it. It’s a great utility to have even outside of this post…) and look for your Ethernet adapter through the ‘Select Device’ combo box. Click the ‘Add Device’ button; you will see some hex output in the lower window of the dialog that presents. Copy this string by selecting it or just use the ‘Hex String to Clipboard’ button. Then, we need to add the following code to your com.apple.Boot.plist in /Extra off the root of your Leopard/Snow Leopard volume. The code you need to add should look like this:

<key>EthernetBuiltIn</key>

<string>Yes</string>

<key>device-properties</key>

<string>4b00000001000000010000003f000000

0100000002010c00d041030a000000000101060

0001c0101060000007fff04001600000062007500

69006c0074002d0069006e0000000500000001</string>

Of course, the string variable you use for ‘device-properties’ should be your own (and not formatted as the above is), or in other words, use whatever was returned to you from EFIStudio. It might be the same as the above, might not. Either way, when you’re done adding this, save the file.

When you next reboot, you’ll notice that the debug message is now gone and you’ll have a nice, clean boot, absent of any debug output — as you’ll satisfy the bootloader, giving it something other than the NULL injection it was complaining about. I tested the above fix — or better, work-around — for a while and from what I found there are no adverse effects to using this method to get rid of the debug boot string.

{ 0 comments }

May

74.55.39.45 & Firefox – Connection of Death

by Dave on May 6, 2010 · 4 comments

Last week at some point, when using Firefox, a XP machine I’ve got developed an issue when hitting slashdot.org, theregister.co.uk, and other sites I commonly check out and read on a day to day basis. When hitting the sites, the browser would load the header and then attempt to hit 74.55.39.45, and then just sit there with the status bar reading ‘Waiting for 74.55.39.45…’. The browser would sit in this state for minutes before finally timing out on the connection and finally rendering out the page for me. It was amazingly annoying. I did a lookup on the IP and it didn’t turn up much, but further browsing seemed to show that the issue would present on ANY site that contained AdSense content.

Now, yes, I might have visited some “suspect” sites in the weeks prior, and yes, I might have installed some suspect software as well. But, one thing for sure, this needed correcting!

At first I thought it just might be Sprint’s T1 service having some temporary routing issues, but if I used ANY browser other than Firefox, the issue did not present. Hmmm… It was local to my machine. Investigation began.

I first checked out my HOSTS file. It was clear and didn’t show anything suspect. I then checked out my add-ins and plugins in Firefox. They all looked okay as well. Regardless, I began to disable most all of them. This did nothing to clear the issue either. So, off to Google the problem.

Seems a bunch of people ran into this annoying malware. It was hard to tell it was malware however as Trend, AVG, Norton, and McAfee turned up nothing. I finally found a link that pointed me to an AV product called Prevx. When I ran this, it returned 10 or “infected” files and registry entries. Eight of these were not “infections” at all. I use SlimFTP, a small FTP daemon; Prevx identified this as a problem executable along with another few benign apps.

There was two entries that were suspect though. One, a file called, MicrosoftDocProp.dll that was located in \Common Files\Microsoft. The file had no version info. Pulling up a process viewer, I found the file attached to almost every running process on my box! There was also a registry key that loaded it under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\. Using the excellent XP utility Unlocker, I was able to delete the file outside of a PE environment and kill off the reg entry. Of course, this shut down Explorer, as it was attached it as well. But, after killing both the file and reg entry and rebooting, all was well.

I’m not sure that if you run into this that the file and/or the reg entry will be the same, but it definitely seems that Prevx will help you identify the culprit and help you kill it. You can either buy Prevx and have it clean for you, or do the killing yourself, as I did after running their free download (it will scan and ID, but won’t clean until you buy a license).

In any case. . . If you run into this, I hope this helps.

{ 4 comments }

Feb

Fixing PartMgr.sys – PartMgr Failing to Start

by Dave on February 17, 2010 · 0 comments

After initially installing XP and transitioning it across multiple platforms over the years (not to mention all the SP updates on top of that), I found the other day a few low level, boot time devices that were failing to load or ‘Start’ correctly (i.e. Code 24 marked with an exclamation point when viewing Hidden Devices->Non-Plug and Play Drivers in Device Manager). Now, many of these were devices that were no longer even installed in the machine, so the fix for them was easy, uninstall them. Many of these were former drive and/or RAID controllers. While uninstalling them however, I noticed that PartMgr, an integral part of the Windows OS, and an important one as it controls how Windows communicates with all of your partitions, was still sitting there with an exclamation point, and an error that stated that the driver couldn’t start, was not present, etc., etc. When looking at its Properties, things became even more confusing as the Driver tab was telling me that the driver/device was started at boot-time, however was still stopped, not present, and failing for whatever reason. Searching the Internet, I came across a lot of people that have run into this issue, but not one that actually got the issue corrected. Being that re-installing Windows, doing an “in place, upgrade” was not an option, I dove into the issue and got things fixed up. For those out there that might run into the same, here’s how to correct it. . .

I’ll take it you know you have the issue. If you’re not sure but with high disk usage, probing around your file system and having Explorer lock up or do strange things, you might want to check. To check, reference how above using Device Manager. Remember, you must ‘Show Hidden Devices’ via the ‘View’ menu. Once identified, here’s the steps…

Access REGEDIT (you can run this from the ‘Run’ menu, located within the Start Menu) and locate the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}
You will notice in the right-hand pane a ‘Name’ of string-value, ‘UpperFilters’. This name should have a data value associated with it. This data value should be a string of ‘PartMgr’. Ensure this exists. If it does not, add it.
Now in REGEDIT, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PartMgr This key should have a ‘Enum’ subkey. Click on the ‘Enum’ subkey. In the right-hand pane, you should see a list of every drive you have located in the machine. If you do not see all of your drives, you now know why things broke down and the driver started to fail at boot. When I first accessed this key, all that was present was the main root key, ‘Root\LEGACY_PARTMGR\0000′.
If the ‘Enum’ key appears to not match what drives you know you have in the machine or is empty, it’s time to have Windows re-enumerate all of the drives in the machine.
To re-enumerate the drives is easy…Simply delete the ‘Enum’ key located under ‘PartMgr’ and reboot. When the machine reboots, it will re-enumerate all of your drives and add them back to PartMgr’s service key. When this is done, the driver will now know what hardware its controlling and it should start and begin doing its job correctly again.

So, that’s all there is to it. It took a while of digging and referencing other “running” machines to understand what the problem was, but in the end, as you can see, the fix is incredibly easy. After I corrected things, the random issues I was having with Explorer locking up and permanently hourglassing when trying to delete and/or rename files went away. Boot times decreased. And, overall things seemed much better with the health of the machine. Of what research I did, I saw that many people seemed to experience this when installing Intel’s Application Accelerator on hardware that didn’t necessarily support the installation of the software (Nice install Intel!).

Anyway. . . hope this helps some of you out there that might come across the issue.

{ 0 comments }