Abnormal exit and leaves many temp file.tmp in itunes diectory

Thanks, I didn't see that you'd tried procmon, which I haven't used much. I thought filemon might be the better choice since something could still have the file open, yet not processing it at the time of the porblem.

Thanks. A lot of my career has focused on improving quality in several domains of IT. You develop a mindset to root out and fix obscure problems and accumulate a lot of stories that are no fun to hear at parties. 🙂

Anyway, back to this problem... Unfortunately, there's no way for us to know exactly what iTunes was doing at the time of the crash or what precisely triggered the ABEND. It's something that has changed in iTunes 7.7 and probably has something to do with how the "iTunes Music Library.xml" file is processed. If this file is "clean", it's quite conceivable that very few people will ever experience this crash.

My library is probably not "clean"... It has evolved through several generations of iTunes; I've had power failures while iTunes was running (but I don't think that the file has been corrupted); I have Classical CDs with titles which make use of several different international character sets, etc. Something somewhere in an 8.5MB file with almost 197,000 lines of XML is making iTunes 7.7 choke; something that iTunes 7.6 does not seem to have any problems with.

I tried starting from scratch by uninstalling all of my Apple software, deleted leftover files (configs, updates, etc.) scattered throughout the system, and reinstalled. I then archived my "iTunes Library.itl" and "iTunes Music Library.xml". I now have a clean system and a clean library... did some quick tests... no crashes. I then rebuilt my iTunes library by importing "iTunes Music Library.xml". Everything imported just fine and my content was back. Unfortunately, iTunes started crashing all over again on exit.

That's all I have to offer at this point; just a hypothesis, no conclusions. I also flipped a coin to see which one of us gets to try the iTunes 7.7.1 update first when it comes out... it came out tails, so you get to try it first! 🙂

Re: 1.
My library profile is quite different from yours; about 5000 songs (all imported from my CD collection; nothing from the iTunes store) and several podcast subscriptions. In total, my content only weighs in at 40MB; quite small by today's standards. The only sources of "pollution" to my XML file, that I am aware of, are: 1) CD track information from Gracenote's CDDB and 2) from (possibly bad) RSS feeds in podcast subscriptions. Hopefully iTunes itself does not contribute and is able to filter out any bad content. If "pollution" is causing the crash, it could explain 1) why relatively few people are experiencing this problem and 2) why the problem comes back after rebuilding the iTunes library.

I'll see if I can find a way to scrub "iTunes Music Library.xml" in order to make it more palatable to iTunes 7.7 but this may require writing some custom code. In any case, there's no excuse for a program like iTunes to fail ungracefully for any reason. It would also be really nice to have a good tool that can verify the integrity of the entire iTunes library and fix any inconsistencies that may arise.

Re: 2.
Sorry, I don't know for sure. Apple changed chipsets in the newer iPods so it's quite possible that they react differently to "errors" in MP3 files (not created by iTunes) than the 5th Generation units or software MP3 players like QuickTime and iTunes.

+>> In total, my content only weighs in at 40MB; quite small by today's standards.+

Sorry... meant to say 40GB; still small by today's standards...

You know, you can just delete the XMl file and itunes will rebuild it.
The important library file is the ITL file.

That's interesting... Apple's how-to guides tell you how to rebuild the ITL file from the XML file. I had no idea that iTunes could do the reverse automatically.

BTW, while tracing iTunes during a normal exit, it sure looked like the XML file was updated, closed, and then re-opened to generate a new ITL file from scratch; it's during this procedure that iTunes pops up the "Saving iTunes Library" progress bar.

I'll be very interested to see what happens if I move the XML file to another directory, let iTunes regenerate it from the ITL as you suggested, and then compare the two XML files afterwords.

Thanks very much for the tip!

+Apple's how-to guides tell you how to rebuild the ITL file from the XML file+.

I know, and that procedure loses some metadata such as date added & last played. As I said, the ITL is the important one. It's the proprietary database that iTunes uses. The XML file is just there for other applications to use, such as lastfm.

Yes, keep your XML file safe in another location while you try it. I'm sure iTunes will rebuild it, since I've done it several times.

BTW, my ITL file is 46.5 MB. I've read posts from users with larger ones.
I don't think you've hit any kind of size limit, is my point.

+>> Apple's how-to guides tell you how to rebuild the ITL file from the XML file.+
>>
+> I know, and that procedure loses some metadata such as date added & last played.+

FYI, that may not be entirely true anymore. I had to recreate the ITL file from XML when I downgraded to v7.6. In my case, most of the metadata remained intact. "Date Added" got trashed of course, but "Last Played" and "Play Count" remained intact; so did my podcast subscriptions and play lists. My podcasts all became unsubscribed so I had to re-subscribe and all podcasts got marked as "new." Also, out-of-the-box smart playlists (like 90's Music) got duplicated. Nevertheless, after a bit of clean-up, all was back to normal. The XML to ITL import also ensured that entries for deleted media files were purged and no longer in any playlist.

Anyway... just wanted to confirm your point that iTunes seems to faithfully recreate the XML file from the ITL file.

These are the files before:
30/07/2008 03:03 PM ... 8,983,138 ... iTunes Library.itl
30/07/2008 03:03 PM ... 8,509,680 ... iTunes Music Library.xml

I then deleted "iTunes Music Library.xml" and ran iTunes and exited:
30/07/2008 03:31 PM ... 8,983,138 ... iTunes Library.itl
30/07/2008 03:31 PM ... 8,509,680 ... iTunes Music Library.xml

Looks good! Just to be sure, I re-ran iTunes again and exited:
30/07/2008 03:39 PM ... 8,983,138 ... iTunes Library.itl
30/07/2008 03:39 PM ... 8,509,680 ... iTunes Music Library.xml

Note: these results were obtained using iTunes 7.6. The file sizes remained the same but I still have to analyze the content to see if anything in the XML files changed. The XML file was created when iTunes closed, not when it opened, so the re-creation of the XML file may be "business as usual", just like the re-creation of the ITL file on exit.

I'm still a bit confused because in the trace, it sure looked like iTunes was creating the ITL file from the XML file on close, which doesn't make any sense to me.

Regardless, hopefully garymc can let us know if anything different happens under iTunes 7.7. Based on my (mis?)understanding at this point, I don't think that regenerating the XML file will fix any of the problems we are experiencing... although I would love to be proven wrong on this.

My understanding of the XML file is that it is purely a liaison file created to allow other programs access to the iTunes library. It is constantly updated to reflect the contents of the ITL file, which is what iTunes itself uses as its database.

If you think there is a library problem, you can use the shift key startup to create a test library:
http://support.apple.com/kb/HT1589
This could also be used to investigate content problems - adding back track a bit at a time.

Another source of odd problems are the iTunes preference files. I haven't heard of them doing this, but they can be deleted which creates new preference files with default settings.
This trouble shooting article contains instructions for removing preference files:
http://support.apple.com/kb/TS1421

I also successfully upgraded iTunes to version 7.7.1 earlier today. It looks like my problems with 7.7.0 have been fixed as well and everything seems to be working normally. Ran ProcMon and the trace looked clean. So far, I'm pretty happy with this release.

Hey, great news!