I am experiencing a problem where it appears like SearchProtocolHost.exe is updating a PST file. The LastWriteTime for the PST file changes to the current datetime and the file grows slightly larger. I am not sure why this is happening. Environment: Windows 7 Enterprise with SP1 (lastest updates), Office Professional Plus 2010 SearchProtocolHost.exe information: Version 7.0.7600.16385; Date 7/12/2009 9:309 PM I do not regularly use Outlook (maybe once a month), but Outlook is loaded on the computer. I have about 15 large (1GB or larger) PST files on the system. Only one of the files is being effected. As it turns out it is a copy of another file. So I have an original PST file in one folder and a copy of that PST file in another folder. Repeatedly the copy version is being changed. The original is being left alone. I used Sysinternals Process Monitor to track down when the change was occuring. I created a little batch file that I run in DOS that does a directory listing of that file once a second. By looking at Process Monitor, I can see the file datetime is correct, then over the next second something happens and the next time the DOS directory listing runs, I can see the file has changed. Basically I have narrowed the event down to one second of process activity. By using a path filter in Process Monitor, I can see that the only process that touches the file at that moment when the datetime changes (other than the DOS directory listing) is SearchProtocolHost.exe - when it does a number of things including a IRP_MJ_WRITE. And I can tell that the file increased in size at the same time. Based on the time of the file timestamp change, looking at what processes were running at time of the file change, and seeing that a process is doing some sort of write to the file, it seems like it is SearchProtocolHost.exe is making the file change. Since Outlook is not open, the file should not be getting changed. The one thing that I thought of to try is to open Outlook and see what - if any - PST file gets opened. Sure enough, the PST file in question was automatically opened. So I closed the file and closed Outlook. (I opened Outlook again to confirm the PST file was no longer set to be open.) I will monitor what happens tonight and post the results. Again I am not 100% positive that SearchProtocolHost.exe is causing the file change. It is possible that something else is the cause - include a virus or malware. But I can find no evidence of either a virus or malware on this system. And ProcessMonitor is not showing anything else touching the file. In light of the fact that this particular PST file was set to be opened in Outlook it seems like SearchProtocolHost.exe is the culprit. Questions: Does SearchProtocolHost.exe actually perform a function against a PST file open in Outlook (even though Outlook is closed)? If so, that is fine. But why would SearchProtocolHost.exe modify the file? Is this expected and normal process for SearchProtocolHost.exe? Is there something else I should be looking at to see why this is happening? Thanks for the help! UPDATE (5/9/2011 - 8:00 AM ET): As I mentioned above, I closed the PST file (that was getting modified) in Outlook so that Outlook only uses my inbox PST file. I ran Processes Monitor again overnight against the PST file that was no opened in my Outlook session. (Remember that the PST file was selected to be opened in Outlook, but Outlook itself was closed. The results were as I expected - the PST was NOT modified. Since I have monitored the "change" to the PST file occuring regularly during the night (idle/scheduled time???), I have a high level of confidence that I have identified the problem of why this particular file was being effected and the other PST files on my computer not being effected. But I will continue to monitor the file for the next few days. Regarding my question above "Does SearchProtocolHost.exe actually perform a function against a PST file open in Outlook (even though Outlook is closed)?" - at this point the answer seems, yes. And with regards to "Is there something else I should be looking at to see why this is happening?" - as Alex posted below, I will test with Windows Search Service disabled. But I will not be able to test this until after I test the change I made fixes my problem of the PST file being modified. I also still have the open questions: 1) Why would SearchProtocolHost.exe modify the file? 2) Is this expected and normal process for SearchProtocolHost.exe? UPDATE (5/13/2011 - 1:00 PM ET): As I mentioned in my last update, I had some testing to perform. I started with two large PST files (1GB or larger). Test file #1 was a copy of the file with which I originally discovered the problem. Test file #2 was a copy of another file. When testing, Outlook was closed. I proceeded to test to see how Windows Search Service affected the PST files by opening them in Outlook in different ways. Here is what I have learned so far: > Test 1 - test file #1 and test file #2 both opened in Outlook but the tree structure for both PST files was not expanded - Result: no change in file last modified datetime stamp or file size for either file. > Test 2 - test file #1 opened in Outlook and tree structure expanded, test file #2 open in Outlook tree structure not expanded - Result: test file #1 showed a change in file last modified datetime stamp but no change in file size, test file #2 showed no change to its file last modified datetime stamp or file size. > Test 3 - Test file #1 opened in Outlook and tree structure was collapsed after previously being expanded, test file #2 opened in Outlook and tree structure expanded - Result: test file #2 showed no change to is file last modified datetime stamp or file size, test file #2 showed a change in the file last modified datetime stamp but not change in file size. > Test 4 - Test file #1 opened in Outlook with tree structure still collapsed but selected when I closed Outlook, test file #2 open in Outlook with its tree structure collapsed - Result: no change in file last modified datetime stamp or file size for either file. This seems to indicate that having the file open in Outlook is not enough to cause the file's last modified datetime stamp to be changed, but if the PST file's tree structure is expanded when Outlook is closed then Windows Search Service modifies the file's last modified datetime stamp. In my opinion, this a problem. The indexing function should not modify the file's modified datetime stamp. But during my testing, the file size never changed. Remember my original problem was that not only was the file modified datetime stamp changing, but also the size of the file increased. In comparing the test environment to the actual production environment where the file timestamp and file size changes were first modified, I realized that the PST had last been opened using Outlook 2007. I now have Outlook 2010 on the system. My theory is the file grew in size because of some PST file conversion change as indexing function is changing the file in some way to a 2010 format (or something along those lines). Unfortunately, I can completely and accurately test this without loading Outlook 2007 again, selecting a 2007 PST version of the file, expanding the tree struction, closeing Outlook, installing an upgrade to Outlook 2010, and monitoring. (I am not willing to test to that extent.) However I did perform the testing requested by Alex. I opened Outlook and expanded the tree structure on both PST files. I then disabled Windows Search Service and monitored the two files for two days. They did not change. So as I mentioned throughout the update, based on this last test and based on reading "Indexing Process in Windows Search (Windows)" on MSDN, it seems that Windows Search Service is the cause of the problem.

Hi, Thanks for posting in Microsoft TechNet Forum. SearchProtocolHost.exe is a process of Windows Search service; to get a correct conclusion, I suggest you try to disable Windows search service to check if the PST file will still be modified in this condition. Regarding SearchProtocolHost.exe, there is a description on it in MSDN article: Search Protocol Host The search protocol host is merely a boxed, host process for protocol handlers. Typically, Windows Search creates two such host processes, one that runs in the system security context and one that runs in the user security context. This separation ensures that data specific to a user is never run in the system context. Windows Search also uses the host process to isolate an instance of a protocol handler from other processes or applications. This way, no outside application can access that specific instance of the protocol handler, and if the protocol handler fails unexpectedly, only the indexing process is affected. Because the host process runs third party code (protocol handlers), Windows Search periodically recycles the process to minimize the time a successful attack has to exploit information in the process. Beyond this, the search protocol host does not affect the crawling of URLs or indexing of items. Hope it helps. Alex Zhao TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tngfb@microsoft.comPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Thanks Alex. Please read the edit "update" in my original post. Closing the PST file in Outlook seemed to prevent SearchProtocolHost.exe from modifying the PST file. I will need to monitor for a few days to confirm. After I do that, I will perform your test. I will create another copy of this PST file and another PST file and open both of them in Outlook. Then with Outlook closed, I will see if either or both files are getting modified again. If they are, this should prove that having the file open in Outlook is what causes the file to get indexed and modified. Then, as you suggested, I will disabled Windows Search Service and see that happens. I will post the results. Also, I read about Search Protocol Host in a number of articles on MSDN. But I don't think I found the exact article you were refering to - so would you please post a URL? Thanks!John

Hi, Thanks for your update. Regarding the MSDN article, it is: Indexing Process in Windows Search (Windows) I would like to know more information about how you test this, so that I can see if it can be reproduced in my lab. Meanwhile, please also keep me updated about the results of the tests you mentioned in your last reply. Thanks. Alex Zhao TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tngfb@microsoft.comPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Thanks Alex. I read the article. It was interesting and informative. I added an update to my original post just a little bit ago. Please review the information in that second update. I describe the testing I did and what I discovered with regards to the datetime stamp changing. I mentioned that in my testing environment, the file size did not change. You will read in the update that I have a possible theory as to why the file size change occured in the original production environment but not in my test environment. And finally I mentioned that the datetime stamp changes stopped when I disabled Windows Search. Please let me know if you need any additional details on my test environment or procedures. As for my original problem - it is not solved, since it appears to be a bug in Windows Search - but I have a good work around which I have described below. The work around is: a) make sure that before I close Outlook that I close all my archive PST files or; b) make sure that before I close Outlook that I collapse the tree struction of all opened PST files.John

Hi, Based on my research, timestamps are updated at various times and for various reasons. The only guarantee about a file timestamp is that the file time is correctly reflected when the handle that makes the change is closed. When processing files, WSS analyzes a set of documents, extracts useful information, and then organizes the extracted information so that properties of those documents can be efficiently returned in response to queries. So as my understanding, it is not a bug of windows search, to get more detailed information about Windows Search, you could refer the following article: Windows Search Overview (Windows) Hope it helps. Alex Zhao TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tngfb@microsoft.comPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi, I am just writing to check the status of this thread. Was the information provided in previous reply helpful to you? Do you have any further questions or concerns? Please feel free to let us know. Alex Zhao TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tngfb@microsoft.comPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi, We will mark it as ‘Answered’ as the previous steps should be helpful for many similar scenarios. BTW, we’d love to hear your feedback about the solution. By sharing your experience you can help other community members facing similar problems. Alex Zhao TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tngfb@microsoft.comPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Alex, Sorry I have not been able to respond until now. I was unexectedly not available with regards to communicating on this issue for the past two weeks. Thanks for you answer above. I did "unmark" your May 16th comment as the answer, because after reading the Windows Search Overview again, I still do not feel that it is working correctly. The overview states: When processing files, WSS analyzes a set of documents, extracts useful information, and then organizes the extracted information so that properties of those documents can be efficiently returned in response to queries. It does not say it will modify the original file. As I mentioned in my original post and the updates - Sysinternals Process Monitor is telling me SearchProtocolHost.exe (and as you explained this is actually WSS) is modifying the file's datetime stamp. If WSS is just extracting information, why is it changing anything? Also with regards to the Outlook 2007 PST file being modified in file size by SearchProtocolHost.exe (and as you explained this is actually WSS) - as I mentioned, I can not test this to the full extent that I would like - but I can take the Outlook 2010 PST file, open it in Outlook 2010, expand the PST's folder tree structure, close Outlook, replace the file with the Outlook 2007 version and WSS will not only change the file datetime stamp, but increase the size of the file. (This is the closest thing I can do to replicate the original conditions of Outlook 2007 having a PST file open and the folder tree structure expanded, then with Outlook closed upgrading to Outlook 2010 and having WSS modify the file.) Again, I just do not understand why WSS is modifying in this case both the timestamp and the filesize. If Outlook is closed - why does it make a difference whether the folder tree structure is expanded or not? If in fact WSS (on a system with Outlook 2010) has to update a 2007 PST file to index it then why are all my Outlook 2007 PST files not affected? It comes down to this: 1) Why is WSS modifying the file size at all? If a file conversion needs to take place. Outlook needs to do it, not WSS. 2) Why is WSS modifying the file date time stamp? It should make no difference to WSS whether a PST's folder tree structure is expanded or not. John John

what is the extend of size increase for the pst files? Sumesh P - Microsoft Online Community Support

Sumesh, I have a done a lot of different testing with regards to this issue, so I have a lot of different results. Here is one of my examples : Original File: Date Modified - 2/5/2009 9:51 AM ; File Size - 1,456,686,080 bytes Changed File: Date Modified - 5/12/2011 5:14 PM ; File Size - 1,477,256,192 bytes I am not sure whether I mentioned this before, when when I test the situation where the file grows in size, it grows a little bit in size each time it is changed. The point being, in the information above, the file has been changed multiple times during the period of time I monitored it, growing a little each time it is modified. If you need me to narrow it down exactly, I can look through the ProcessMonitor logs. Just let me know what you specifically need. John John

WDS does not access PSTs directly but has a protocol handler that goes through outlook. SearchProtocolHost hosts the Outlook plug-in that is accessing the PST. The MAPI Protocol Handler does not modify the PST directly. However, when the PST is opened, it can kick off background tasks which might modify the contents of the PST like the one you mentioned earlier. Also note that according to the numbers you provided above, the size of the file actually decreases in time. This could be due to email archiving, compacting or deleting of emails. Again, Windows Search should have nothing to do with this. Sumesh P - Microsoft Online Community Support

Sumesh P, Thanks for your response. With regards to the file sizes, I must have made a typo - or maybe I mislabeled the numbers - because the size definately increased. I will check when I get home and post an update. Sorry about wasting your time with bad or incorrectly labeled numbers. With regards to your other comments... You stated that WDS does not access the PST directly. You also stated that SearchProtocolHost holds the Outlook plug-in. And that the MAPI Protocol Hander does not modify the PST directly. If I understand these statements, SearchProtocolHost runs WDS within its process and WDS accesses the PST file through the MAPI Protocol Handler (also refered to by you as the Outlook plug-in). Correct? I might have not gotten that 100% correct, but I think you are saying SearchProtocolHost ultimately runs a plug-in that reads the PST file. And you are saying the plug-in should not modify the PST file - but a background task maybe does modify it. In my notes I mentioned that I ran Process Monitor and it seems to show SearchProtocolHost modifying the file. There is no other process touching the file. And Outlook is not opened. (I think I still have the Process Monitor logs and I will post screen prints from them.) So if it is a background task that is modifying them, it is run under SearchProtocolHost also. So in short, I am back to trying to figure out why the file's date and file size are being modified without Outlook being open. Does Microsoft consider this to be normal? And why does closing Outlook while having the tree structure in a PST file expanded expanded trigger this event? Again is this normal, expected behavior. I do not think so, that is why I am contining to try to help by sharing the information I have in this thread. Thanks for your help. I will post again later today when I have the other information that I promised to post. UPDATE: Here are the correct file sizes: Original File: Date Modified - 2/5/2009 9:51 AM ; File Size - 1,456,686,080 bytes Changed File: Date Modified - 5/12/2011 5:14 PM ; File Size - 1,477,256,192 bytes (As I thought I posted the file sizes on the wrong lines. The correct numbers are posted here. I also corrected the original post. Sorry!) ALSO: Here is a screen print from Process Monitor showing the file datetime stamp change. (I wish I had saved the log file for the file size change, but I did not. I guess I can rerun the test if you want and capture those results.) Anyway, when I ran Process Monitor, I filtered on the file name - so any process that touch the file got saved. (too much information to save everything since I have no idea when WDS will run under SearchProcesshost). Anyway, I ran a looping DOS based "dir" command that displayed the file that ran every second. So that way, we can see the before and after file date, time and size. Look for the LastWrite Time to change from 2/5/2009 to 5/7/2011. Hope this helps. Oh, here is the link to the screen print: http://s1111.photobucket.com/albums/h466/tcp25john/?action=view&current=36a21648.jpg UPDATE: 06/02/2011 - 11:00 PM ET I just completed a test where both the file datetime stamp changed and the file grew in size. I have screen prints of the before and after file date/time/size. I have the actual before and after PST files. I have the Process Monitor Log File in PML and CSV format. I can email everything but the PST files to you. Please email me your email address. (As moderator, I assume you have access to find out my email address.) If you feel you need the PST files also, just mention it in the email. I can discuss the issue via email. Thanks. John

Sorry to butt in but what happens is you create a new test PST file? Lets put three documents in it. One at root, and create two subfolders and put one in each folder. Then if you do catch this folder growing in size at least you won't have GIGs of data to worry about and will also have a sample test that includes PST files you can then send off elsewhere. :-) MC_JAS wrote: > > >Sumesh P, > >Thanks for your response. With regards to the file sizes, I must have made a typo - or maybe I mislabeled the numbers - because the size definately increased. I will check when I get home and post an update. Sorry about wasting your time with bad or incorrectly labeled numbers. > >With regards to your other comments... > >You stated that WDS does not access the PST directly. You also stated that SearchProtocolHost holds the Outlook plug-in. And that the MAPI Protocol Hander does not modify the PST directly. If I understand these statements, SearchProtocolHost runs WDS within its process and WDS accesses the PST file through the MAPI Protocol Handler (also refered to by you as the Outlook plug-in). Correct? > >I might have not gotten that 100% correct, but I think you are saying SearchProtocolHost ultimately runs a plug-in that reads the PST file. And you are saying the plug-in should not modify the PST file - but a background task maybe does modify it. In my notes I mentioned that I ran Process Monitor and it seems to show SearchProtocolHost modifying the file. There is no other process touching the file. And Outlook is not opened. (I think I still have the Process Monitor logs and I will post screen prints from them.) So if it is a background task that is modifying them, it is run under SearchProtocolHost also. > >So in short, I am back to trying to figure out why the file's date and file size are being modified without Outlook being open. Does Microsoft consider this to be normal? And why does closing Outlook while having the tree structure in a PST file expanded expanded trigger this event? Again is this normal, expected behavior. I do not think so, that is why I am contining to try to help by sharing the information I have in this thread. > >Thanks for your help. I will post again later today when I have the other information that I promised to post. > >UPDATE: > >Here are the correct file sizes: Original File: Date Modified - 2/5/2009 9:51 AM ; File Size - 1,456,686,080 bytes Changed File: Date Modified - 5/12/2011 5:14 PM ; File Size - 1,477,256,192 bytes (As I thought I posted the file sizes on the wrong lines. The correct numbers are posted here. I also corrected the original post. Sorry!) > >ALSO: > >Here is a screen print from Process Monitor showing the file datetime stamp change. (I wish I had saved the log file for the file size change, but I did not. I guess I can rerun the test if you want and capture those results.) Anyway, when I ran Process Monitor, I filtered on the file name - so any process that touch the file got saved. (too much information to save everything since I have no idea when WDS will run under SearchProcesshost). Anyway, I ran a looping DOS based "dir" command that displayed the file that ran every second. So that way, we can see the before and after file date, time and size. Look for the LastWrite Time to change from 2/5/2009 to 5/7/2011. Hope this helps. Oh, here is the link to the screen print: http://s1111.photobucket.com/albums/h466/tcp25john/?action=view¤t=36a21648.jpg > > > >UPDATE: 06/02/2011 - 11:00 PM ET I just completed a test where both the file datetime stamp changed and the file grew in size. I have screen prints of the before and after file date/time/size. I have the actual before and after PST files. I have the Process Monitor Log File in PML and CSV format. I can email everything but the PST files to you. Please email me your email address. (As moderator, I assume you have access to find out my email address.) If you feel you need the PST files also, just mention it in the email. I can discuss the issue via email. Thanks. > > >John > > Hay

Excellent investigation, I am seeing the same thing, SearchProtocolHost.exe is messing with the PST files both archive and outlook main files, and seems changing the sizes , and "possibly" contents. This needs to be investigated by MS and clearly explained to public on why and what going on. Who/which are the so called "Third Party Component" used by Windows Search?

Investigate - Thanks for the "excellent investigation" compliment. I too hope that I get a satisifactory answer from Mcrosoft. HarryVerge - Thanks for the suggestion. I had previously tried to create a new PST file in Outlook 2010 and populate it with data, but I could not recreate the file datetime stamp change or the file size growth isssue. But based on your suggestion, I decided to try again. I let the file sit for over two and a half days, but the results were the same. There appears to be no file datatime stamp change or file size increase when the PST file is originally created in Outlook 2010. Sumesh P - I did want you to know that I searched my archives for smaller PST files that were last used under Outlook 2007. I tested with one that was about 100 MB and another that was about 5 MB. Both of them experienced the datatime stamp change and size increase issue. And the change occured with the 5MB file so fast that I did not even have time to create a before screen print. But I do have the before and after PST files as well as the Process Monitor Log file in PML and CSV format for all tests. As soon as you send me your email address, I can send you the 5 MB PST test results with the PST files to you in a zipfile that is 2 MB in size. You can have all the data for the 100 MB test, but all the test data and logs are about 100 MB in size. I suggest that you start with the 5 MB PST test results, see what I am seeing and then tell me if you want more information. Thanks!John

Interesting about the new PST not seeing any activity when created in Outlook2010. Again, just curious but was the "problem" PST created with new PST structure or was it the old "Outlook 97-2002 data File" format? If it was older format might also be worth eliminating that from the mix by creating another test PST in old style...Hay

Good question HarryVerge. I have done lots of testing, but I have not tested all the different variables that existed. Let me explain what I know and what I suspect. I know that SearchProtocolHost (apparently WSS) is repeatedly changing of the datetime stamp and the file size occurs in PST files initially created in an older version of Outlook that have been opened in Outlook and have a folder selected in Outlook when Outlook is closed. This is new information - originally thought the tree structure needed to be expanded, but in my small test files, all I did was select the inbox folder (when before I closed Outlook) since there was not nested folder structure to expand. I have no exact testing details the tell me how many time the file size changes, but like I said, if it changes just once as a result of a coversion to 2010 format, I would be fine that. But I have observed it change multiple times in my testing. But it is the file datetime stamp change that bothers me the most. Even in situations where the file size does not change, the datetime stamp does change. And it will keep changing again and again and again. I observered over a week of changes - and in fact that was what first alerted me to the problem. I noticed that a particular file was backing up again and again and again as a result of the date changes. Again, one change for a conversion is fine with me. Multiple changes of the file size and file datetime stamp seem to indicate a problem. AND, why is it only the file selected in Outlook. (Remember that Outlook.) If WSS is indexing all PST files, then why are the PST not selected in Outlook not undergoing this file datetime stamp and file size change issue. Is WSS not indexing them. (yet another thing to test.) Looking back at your question regarding old Outlook data format, none of my production or test files discussed above are the old format. When I look at the Advance PST properties, it states "Outlook Data File" which I understand to be the new format. That being said, the PST files created in Outlook 2007 or earlier, do seem to act different in my testing than PST files created in Outlook 2010. I think I am going to do one last test. I am going to create a new Outlook 2010 PST file. Copy all the data from an old Outlook 2007 PST file (1 GB or larger) and see if that file is changed by WSS in any way. UPDATE - 06/06/2011 6:18 PM ET Okay I ran the test. I created a new Outlook 2010 PST file. I copy all the data from an old Outlook 2007 PST file (1 GB or larger). I monitored the file to see if it was changed by WSS in any way. Immediately after copying the data into the PDT file and then closed Outlook. It appeared there was some PST file changes that occured. But after that finished, I monitored for changes. The results are file datetime stamp changes by WSS - but there was no file size changes. That is good. But I still find it odd that the datetime stamp of the file is being changed by WSS (or something else under SearchProtocolHost). Time for Microsoft to jump in and perform some controlled testing to see if my results can be duplicated!!! John

Procmon logs will not help in this case as it will not tell me what changes are being made. I am checking to see if there is some sort of tracing available to track the changes. If you have a Premier account with Microsoft, i suggest that you open a case with us so that we can look into this issue in further detail. Sumesh P - Microsoft Online Community Support

Thanks for the response Sumesh P. At present, I do not have a Premier Account, so I can not open a case with Microsoft there. You should know that I developed a workaround to this issue back when I first discovered it. I just do not close Outlook with the PST open. All the testing and communications that I did over the past month was simply to document the problem I discovered in order to help other users and Microsoft. If you want me to run another test with a better tracking tool that you send me, I would be glad to do that. I will just wait to hear from you again. Thanks!John

I checked with some folks here and could not find a tool to track the changes. If this is a pressing issue then i request you to open a case and work with our outlook team to look at any available tools/options to troubleshoot this further. You might also want to turn off any 3rd party outlook add-ins that you might have outside of search. Please visit the below link to see the various paid support options that are available to better meet your needs.http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone Sumesh P - Microsoft Online Community Support

Sumesh P. As I mentioned in my previous post dated Monday, June 13, 2011 1:39 PM I said: I developed a workaround to this issue back when I first discovered it. I just do not close Outlook with the PST open. I also said: All the testing and communications that I did over the past month was simply to document the problem I discovered in order to help other users and Microsoft. I feel it is time for Microsoft to pick up this issue and run with it - or as a representative of Microsoft are you planning to leave this potentionally discovered bug as just a discussion in the forums which will not be investigated or tested? At this point, all I am trying to do is to get this issue in front of the right people so they can then determine whether this is worth investigating or not. It is up to Microsoft to decide what to do about this issue - be it a programing fix, documenting the issue in a Knowledge Base article describing the problem and the work around, or simply doing something nothing. I appreciate your concern that I might have an going issue and as a result you are directing me to support. But as I stated before in different words, I do not have a support issue since I developed a work around. As a result, I feel there is no need for me to contact paid support - UNLESS, that is how Microsoft is set up to receive bug reports. If that is the case, then just let me know and I will open a support case - but I will not be paying for support, even if the support charge is refunded. Personally, I think it would be easier for everyone if you just take the URL for this thread, and submit it as a bug report internally within Microsoft to whichever team you feel is appropriate. And if someone who is investigating this issue as a bug report decides to get in touch with me, I would be glad to share my test data, criteria and results. Please reply in this thread with an update no later than July 15th. In your post, please let me know whether a) you have already internally submitted this as a potential bug. b) who you would like me to contact to submit this as a potential bug. Thank you! John

I will pass pass this information along. I have already shared it with some of the concerned. Thanks for your indepth analysis report.Sumesh P - Microsoft Online Community Support

I too am experiencing the SearchProtocolHost.exe seemingly changing files' metadata slightly (in any case the timestamps). In my situation I'm developing a website and a co-developer is saving stylesheets over my samba-shared files, using the EditPlus application. We're using this application because it has the feature to automatically check whether files have been modified, before saving. It displays this notice each time the file is saved, even if no other user-invoked process should have changed the file. Here's an excerpt from the Process Monitor log, I removed the pathname for readability:The small difference in ChangeTime seems to signal the file has been changed. 11:56:50.2734998 Explorer.EXE 2876 QueryBasicInformationFile index.css SUCCESS CreationTime: 18/8/2011 9:25:13, LastAccessTime: 18/8/2011 9:25:13, LastWriteTime: 31/8/2011 11:56:48, ChangeTime: 31/8/2011 11:56:48, FileAttributes: A 11:56:50.2735123 Explorer.EXE 2876 CloseFile index.css SUCCESS 11:56:50.2738358 Explorer.EXE 2876 CreateFile index.css SUCCESS Desired Access: Read Attributes, Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened 11:56:50.2738601 Explorer.EXE 2876 QuerySecurityFile index.css BUFFER OVERFLOW Information: Owner, DACL 11:56:50.2738749 Explorer.EXE 2876 QuerySecurityFile index.css SUCCESS Information: Owner, DACL 11:56:50.2738902 Explorer.EXE 2876 CloseFile index.css SUCCESS 11:56:50.2742840 Explorer.EXE 2876 CreateFile index.css SUCCESS Desired Access: Read Attributes, Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened 11:56:50.2743098 Explorer.EXE 2876 QuerySecurityFile index.css BUFFER OVERFLOW Information: Owner, DACL 11:56:50.2743243 Explorer.EXE 2876 QuerySecurityFile index.css SUCCESS Information: Owner, DACL 11:56:50.2743391 Explorer.EXE 2876 CloseFile index.css SUCCESS 11:56:52.3814526 SearchProtocolHost.exe 2912 CreateFile index.css SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Open Reparse Point, Open Requiring Oplock, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened 11:56:52.3814887 SearchProtocolHost.exe 2912 FileSystemControl index.css SUCCESS Control: FSCTL_REQUEST_FILTER_OPLOCK 11:56:52.3815024 SearchProtocolHost.exe 2912 QueryStandardInformationFile index.css SUCCESS AllocationSize: 8,192, EndOfFile: 7,306, NumberOfLinks: 1, DeletePending: False, Directory: False 11:56:52.3815134 SearchProtocolHost.exe 2912 QueryBasicInformationFile index.css SUCCESS CreationTime: 18/8/2011 9:25:13, LastAccessTime: 18/8/2011 9:25:13, LastWriteTime: 31/8/2011 11:56:52, ChangeTime: 31/8/2011 11:56:52, FileAttributes: A This is getting annoying. Perhaps the BUFFER OVERFLOW behavior is causing this? *edit* I expected more from the code block, like proper indenting/TABs, not to mention not breaking out of this site's design. Anyway, it's on pastebin too: http://pastebin.com/53q7Hxjq .

I too am experiencing the SearchProtocolHost.exe seemingly changing files' metadata slightly (in any case the timestamps). In my situation I'm developing a website and a co-developer is saving stylesheets over my samba-shared files, using the EditPlus application. We're using this application because it has the feature to automatically check whether files have been modified, before saving. It displays this notice each time the file is saved, even if no other user-invoked process should have changed the file. Here's an excerpt from the Process Monitor log, I removed the pathname for readability:The small difference in ChangeTime seems to signal the file has been changed. 11:56:50.2734998 Explorer.EXE 2876 QueryBasicInformationFile index.css SUCCESS CreationTime: 18/8/2011 9:25:13, LastAccessTime: 18/8/2011 9:25:13, LastWriteTime: 31/8/2011 11:56:48, ChangeTime: 31/8/2011 11:56:48, FileAttributes: A 11:56:50.2735123 Explorer.EXE 2876 CloseFile index.css SUCCESS 11:56:50.2738358 Explorer.EXE 2876 CreateFile index.css SUCCESS Desired Access: Read Attributes, Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened 11:56:50.2738601 Explorer.EXE 2876 QuerySecurityFile index.css BUFFER OVERFLOW Information: Owner, DACL 11:56:50.2738749 Explorer.EXE 2876 QuerySecurityFile index.css SUCCESS Information: Owner, DACL 11:56:50.2738902 Explorer.EXE 2876 CloseFile index.css SUCCESS 11:56:50.2742840 Explorer.EXE 2876 CreateFile index.css SUCCESS Desired Access: Read Attributes, Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened 11:56:50.2743098 Explorer.EXE 2876 QuerySecurityFile index.css BUFFER OVERFLOW Information: Owner, DACL 11:56:50.2743243 Explorer.EXE 2876 QuerySecurityFile index.css SUCCESS Information: Owner, DACL 11:56:50.2743391 Explorer.EXE 2876 CloseFile index.css SUCCESS 11:56:52.3814526 SearchProtocolHost.exe 2912 CreateFile index.css SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Open Reparse Point, Open Requiring Oplock, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened 11:56:52.3814887 SearchProtocolHost.exe 2912 FileSystemControl index.css SUCCESS Control: FSCTL_REQUEST_FILTER_OPLOCK 11:56:52.3815024 SearchProtocolHost.exe 2912 QueryStandardInformationFile index.css SUCCESS AllocationSize: 8,192, EndOfFile: 7,306, NumberOfLinks: 1, DeletePending: False, Directory: False 11:56:52.3815134 SearchProtocolHost.exe 2912 QueryBasicInformationFile index.css SUCCESS CreationTime: 18/8/2011 9:25:13, LastAccessTime: 18/8/2011 9:25:13, LastWriteTime: 31/8/2011 11:56:52, ChangeTime: 31/8/2011 11:56:52, FileAttributes: A Btw, I expected more from the code block, like proper indenting/TABs, not to mention not breaking out of this site's design. Anyway, it's on pastebin too: http://pastebin.com/53q7Hxjq . This is getting annoying. Perhaps the BUFFER OVERFLOW behavior is causing this? *edit* Nope, BUFFEROVERFLOW is normal behavior for ProcMon. See http://blogs.technet.com/b/markrussinovich/archive/2005/05/17/buffer-overflows.aspx .