Search

Debugger hangs VS for a long time when coming out of debug mode by CoolDadTx

Active

118
0
Sign in
 to vote
Type: Bug
ID: 504538
Opened: 10/27/2009 10:35:37 AM
Access Restriction: Public
Duplicates: 524683
5
Workaround(s)
55
User(s) can reproduce this bug
The debugger is frequently (read: once an hour or more) hanging VS for a long period of time (read: over a minute) when debugging stops. Unfortunately it is not related to any particular action that I can see. I've noticed it a lot when interacting with the Output window while debugging but I can replicate it without the Output window as well. Unfortunately it is proving to be very difficult to narrow down. I'm reporting this in hopes that it is a known issue or that there is a suggestion on how to diagnose what is going on so it can be corrected.
Details (expand)

Product Language

English

Version

Visual Studio 2010 Beta 2

Operating System

Windows 7

Operating System Language

English

Steps to Reproduce

Not reliably reproducible but it happens a lot. I'm generally debugging a WPF project but it doesn't seem to matter whether it is a new project or an existing one. The problem occurs after I've been debugging a while. When exiting debug mode (generally by using Stop Debug) then VS hangs.

Additionally the debugger hangs when starting up (if you don't shut down first). I was able to trap this scenario and will append the debugger output (after attaching from another instance) and call stack for the time VS hung.

Actual Results

VS hangs. Normally it isn't eating up any CPU cycles. It is just deadlocked. Same thing when you start debugging again after the problem has occurred the first time.

An interesting scenario occurred while VS was stalled. I hooked up the hung VS instance to another VS2010 debugger instance. The output window showed a thread exiting after a while. This occurred for quite a few threads. Occasionally an exception was thrown and handled. After a while VS suddenly generated a bunch of exceptions (first chance) in the output window and then VS started responding again. Stopping VS at this point does not hang but there are a lot of exceptions generated inside VS.

I'm attaching the call stack and output for the stall when starting debugging after the stop hangs as that is the best I can provide until the problem can be narrowed down further.

Expected Results

The debugger shouldn't hang VS for over a minute on starting or stopping the debugger.
      You can indicate your satisfaction with how Microsoft handled this issue by completing this quick 3 question survey. [Details]

 

File Attachments
File Name Submitted By Submitted On File Size  
StartDebugStopDebug_Output.txt (restricted) CoolDadTx 10/27/2009 -
StartDebug_Output.txt (restricted) CoolDadTx 10/27/2009 -
StartDebug_CallStack.txt (restricted) CoolDadTx 10/27/2009 -
CallStackAtFirstChanceException_NoVSHost.txt (restricted) CoolDadTx 11/10/2009 -
DebuggerOutput_NoVSHost.txt (restricted) CoolDadTx 11/10/2009 -
Sign in to post a comment.
Posted by Bernardo Salazar on 9/30/2011 at 2:43 PM
The thing is only getting worse. Now disabled intellitrace, installed KB2106584 and nothing. HELP!
Posted by Bernardo Salazar on 9/30/2011 at 2:24 PM
I think that i solved the problem in my VS2010 installation. I removed RTFTOHTML utility (used to copy a selected text in IDE, and paste the code in MSDN forums) and VS debug return to normal behavior. If persist the problem i write again.
Posted by Tristan2 on 2/15/2011 at 11:40 AM
Installed hotfix KB2106584. VS still hangs after exiting debugger. Task manager does not list VS as 'Not Responding'; however, VS no longer redraws itself.
Posted by Microsoft on 10/11/2010 at 10:38 AM
Hello,

This bug is for some reason showing as "Active" on this connect site even though it has been closed for over 10 months.

If you are encountering this issue, please try installing a recently released hotfix from the debugger team from http://code.msdn.microsoft.com/KB2106584

If that does not address the hang issue, please email devperf@microsoft.com with the details of your issue and someone will follow up with you to get more information about your problem and try to help diagnose the cause.

Best Regards,
Visual Studio Debugger
Posted by Pat Piccolo on 9/15/2010 at 8:42 AM
I started seeing this problem after installing some of the axTools into Visual Studio (CodeMap, CodeSmart, etc). Check to see if you have these tools installed (Tools/Extension Manager). If so, try deleting all .vs10x files (so far as I can tell, these are settings files, much like VS's own SUO files). Once I removed the .vs10x files, and reloaded my solution, my debugging delay went away. The axTools will recreate the .vs10x files.
Posted by Jon Theriault on 9/2/2010 at 6:15 AM
I've tried disabling IntelliTrace but that doesn't resolve the issue. Disabling the Visual Studio Hosting Process for the project does the debugger stop in the normal amount of time but the delay for the debugger to start up is now just as long as the delay was with the vshost enabled.

I'm running XP SP3. Please let me know if there's anything I can do or try that would help.
Posted by Jon Theriault on 9/1/2010 at 4:03 AM
I'm also getting the hang. I tried running the Performance Diagnostic tool but I just get a "Starting Xperf profiling. Please wait..." message in the status bar and the progress bar keeps spinning. After ten minutes I give up. I've tried it a few times.
Posted by Raul Herrero on 8/10/2010 at 11:31 AM
I have encountered this problem in past versions of the product and just now got it with VS2010 Version 10.0.30319.1 RTM.
I am working on a standard ASP.Net application and am just now experiencing the problem whenever I jump into the source view of an aspx page that I just applied a large CSS file to.
I think what is happening is that I have the source view as the current page when I start debugging. So when I am done, the page becomes active and the IDE just hangs for minutes. (It seems to be running through some kind of process of verifying the CSS and/or applying the styles to the layout or who knows what it’s doing?)
Posted by Jacob Page on 7/13/2010 at 5:52 PM
This happens all the time for me in my Silverlight 4 application. When watching VS in task manager, I see it ballooning to over a gigabyte in memory usage as this occurs. This incidentally frequently crashes VS for me if it takes up too much memory (I'm forced to run this under Windows XP, 32-bit). I think this has to do with the XAML designer since opening XAML in the designer causes tons of memory to get allocated, and I've only seen the coming-out-of-debug thing happen when I have XAML files open, even when they're not opened in designer mode.
Posted by Dave Rathbone on 6/16/2010 at 5:52 AM
I have the same bug in VS2008 and on VS2010. My program runs ok but after clicking debug hangs for 10 to 12 mins. My thought is that I have envoked multi threads that have not finished running, when my VB code exits during debug break. I made my code tidy up all threads I started via my own exit command and this works 9 times out of 10.
Q? Does VS clean up the thread pool after a debug exit to the state before the user ran his application?

Its making me feel that multi threading is still handled by Ronnie McDonald with Intel doing the hardware sales!
Posted by Jason Lavigne on 6/9/2010 at 9:43 AM
Any suggestions for this yet? I am getting the same thing in Version 10.0.30319.1 RTMRel, the interface stops responding to the mouse. The odd part is not everything stops responding to the mouse click, for example I can edit a .cs file just fine and the mouse works, but when I switch to editing a .aspx file, no mouse. A restart of VS does solve it, for a while, but then it does return. Another example is some buttons stop responding but other parts of the interface is ok. Could this be a WPF issue??
Posted by cslater on 5/24/2010 at 2:38 PM
Still happens with the GM version.

I can't believe you guys at MSFT have so much trouble reproducing this issue. Almost everyone I know using VS2010 has run into this issue.

I hope disabling the hosting app helps work around the issue
Posted by Ray Dyce on 5/10/2010 at 1:20 AM
This hunk of crap still has the problem... should have stayed with the only EVER use SP1 approach..

ARGH!!!
Posted by Microsoft on 4/19/2010 at 6:07 PM
@mharen,

Could you please follow the instructions above for collecting a performance trace? (repeated here):
Download and install the Visual Studio 2010 Diagnostic tool located at: http://visualstudiogallery.msdn.microsoft.com/en-us/e8649e35-26b1-4e73-b427-c2886a0705f4. Once you have installed the tool:
-    Open your project in Visual Studio (do not begin debugging yet)
-    Open the “PerformanceDiagnostics” application that was just installed
-    On the ETW/Xperf tab, select ‘Default’, click ‘Start Profiler’
-    Reproduce the hang
-    Click ‘End Profiler’, wait
-    Click ‘View Profiles’; the newest .etl file is the file that we are interested in

and upload it to the following workspace:
URL: https://sftus.one.microsoft.com/choosetransfer.aspx?key=b075e447-fbdd-4d6c-ad86-f146c99a509c
Password: fwBud@xV{S

Thank you,
Visual Studio Debugger
Posted by mharen on 4/17/2010 at 11:59 AM
I'm seeing this on VS2010 Pro RTM, just installed a few days ago
Posted by Microsoft on 1/6/2010 at 5:44 PM
Hello,

We believe that we have determined the cause of this hang and fixed the issue. We have created a pre-Release Candidate build that we would like to provide to anyone experiencing this issue to be sure that we have fully fixed the problem. Note: In order to obtain this build you will be required to sign a Microsoft Non-Disclosure Agreement (NDA).

If you are interested in obtaining and evaluating the build with the fix for this issue, please contact me at andrehal@microsoft.com and I will provide further details.

Best Regards,
Andrew Hall
Visual Studio Debugger
Posted by Microsoft on 12/4/2009 at 10:50 AM
One clarification, the performance tool will install to:
"C:\Program Files\Microsoft\PerformanceDiagnostics"

or for a 64 bit version of Windows:
"C:\Program Files (x86)\Microsoft\PerformanceDiagnostics"
Posted by Microsoft on 12/3/2009 at 5:30 PM
Hello,

It is a top priority for the IntelliTrace team to address this. Unfortunately we are not able to reproduce this issue in our internal labs. Therefore we need the help of customers experiencing this issue to help us determine the exact cause(s), and verify that we fix it appropriately for the RTM release of Visual Studio 2010. Our ask from customers who are willing to assist us, is that you collect ETW traces using the Visual Studio 2010 Diagnostic tool located at: http://visualstudiogallery.msdn.microsoft.com/en-us/e8649e35-26b1-4e73-b427-c2886a0705f4. Once you have installed the tool:
-    Open your project in Visual Studio (do not begin debugging yet)
-    Open the “PerformanceDiagnostics” application that was just installed
-    On the ETW/Xperf tab, select ‘Default’, click ‘Start Profiler’
-    Reproduce the hang
-    Click ‘End Profiler’, wait
-    Click ‘View Profiles’; the newest .etl file is the file that we are interested in

Then, please open the Windows Event Viewer (on Vista and above typing “Event Viewer” into the Start Menu search bar will bring this up), and under Windows Logs -> Application see if any of the recent events are for the VSTraceLog.exe process.

Once you have checked the Event Viewer, and collected the traces, please email me at andrehal@microsoft.com with the Windows Event Viewer information, and to let me know you have traces. I will then provide you with a secure workspace to upload the traces to.

Thank you very much for your assistance on this issue,
Andrew Hall
Program Manager
Visual Studio Debugger
Posted by Sebastien Bach1 on 12/3/2009 at 2:34 AM
i'm tired with this bug... please help us
Posted by Microsoft on 12/1/2009 at 5:32 PM
Hello,

Thank you all very much for your engagement on this issue. The hang reported in this bug is the result of IntelliTrace hanging for up to 2 minutes when debugging is stopped. To answer one of the questions previously posted, the feedback item 498240 (https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=498240) is not the same issue that is reported here. 498240 is an IDE/Project System issue which causes the “Visual Studio is waiting for an internal operation to complete” message.

Unfortunately releasing a QFE for a Beta release is not possible at this time, however there is a simple workaround which is to disable IntelliTrace. To disable IntelliTrace, navigate to Tools->Options->IntelliTrace, and uncheck “Enable IntelliTrace”. Due to the difficult nature of diagnosing the exact cause of hangs, we are interested in working with anyone who appears to be experiencing this issue to verify that this problem has indeed been addressed for the final release of Visual Studio 2010.

Please contact me at andrehal@microsoft.com if you have any further questions about this issue or want to provide additional feedback.

Best Regards,
Andrew Hall
Program Manager
Visual Studio Debugger
Posted by dotScience on 11/24/2009 at 7:24 PM
I can now reliably confirm the amount VS 2010 beta 2 spends "frozen" has increased dramatically after installing the Office Pro 2010 beta, and the Visio Pro 2010 beta.

I estimate it is now unusable more than 60% of the time. And having two different dialogs pop-up (sometimes), one in a silvery grey coming up from the taskbar area, and another larger one with an option to "Continue Waiting" do not help at all.
Posted by Ralph57Cbk on 11/22/2009 at 2:17 AM
I agree wit UNT1TLED. We seriously need a Patch or Hot fix otherwise VS2010 Beta 2 is history!
Posted by dotScience on 11/21/2009 at 9:20 PM
After installing the Office 2010 Pro beta, and the Visio 2010 beta, and all their associated updates, it seems like VS 2010 beta two hangs even more frequently (of course, I don't have hard statistics); my perception is VS 2010 beta two is now unavailable more than 50% of the time.
Posted by Jarem on 11/20/2009 at 3:46 PM
Oh you fixed it? That's great. I'm happy for you. Can we get a patch or something so we can continue to find more bugs?
Posted by CoolDadTx on 11/20/2009 at 6:30 AM
I'd definitely like to see a QFE for this so we can confirm the fix. Given that it was so hard for MS to duplicate we want to make sure that it is the problem that was fixed. If this issue gets into RTM then MS is going to have to release a QFE shortly after release before the backlash gets intolerable. It is truly a showstopping bug.
Posted by dotScience on 11/19/2009 at 11:14 PM
"Thank you for your feedback. We have resolved this issue and the RTM build should be fixed. "

How about a hot-fix for those of us for whom VS 2010 beta 2 is unusable for at least twenty minutes per hour.

thanks, Bill
Posted by JGTM on 11/19/2009 at 10:21 PM
Glad to know that the issue is reproduced and fixed, finally.

Could you please further confirm that the issue reported in FeedbackID=498240 is the same as (or highly relevant to) this one? IMHO, these bugs are really the killer issues for preventing people for evaluating the beta 2 and even final product (if they're still there). Considering the next release drop (maybe the one RC or directly RTM) will be hold for nearly three to four months, and there are stilll many things for us to explore for issues, this hanging bug really hurt our productivity heavily. Is there possible to give us a QFE to address the issue locally?

Thanks!
Posted by Microsoft on 11/19/2009 at 6:01 PM
Thank you for your feedback. We have resolved this issue and the RTM build should be fixed.
Posted by JGTM on 11/16/2009 at 7:14 PM
I think this bug is the same one as this: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=498240.

Maybe you guys could possibly merge there two issues and pay more attention to this real show stopper.
Posted by Asbjørn on 11/15/2009 at 5:45 AM
Sorry for the extra post, but I wanted to add that for me it seems to be linked to the XAML editor. If have a XAML file in the foreground and have made edits, VS will freeze when debugging.
Posted by Asbjørn on 11/15/2009 at 5:35 AM
I can reproduce this consistently with or without the hosting process enabled. I'm running Windows 7 RTM x64. I have a project that does this all the time. I can send it along if needed. Just let me know.
Posted by Ralph57Cbk on 11/14/2009 at 6:30 AM
I too am expieriencing this problem. The IDE hangs perioically (not always), when closing Windows Forms applications which were started with debugging (F5).
Posted by Wokket on 11/10/2009 at 6:18 PM
I'm also seeing this, with a very simple WPF application.

Running Win7 RTM 32bit under a Native boot VHD.

Breaking into the process from another VS instance is generally showing threads locked up with tracing/logging related call stacks.

eg:
[In a sleep, wait, or join]    
mscorlib.dll!System.Threading.WaitHandle.InternalWaitOne(System.Runtime.InteropServices.SafeHandle waitableSafeHandle, long millisecondsTimeout, bool hasThreadAffinity, bool exitContext) + 0x2b bytes    
mscorlib.dll!System.Threading.WaitHandle.WaitOne(int millisecondsTimeout, bool exitContext) + 0x2d bytes    
Microsoft.VisualStudio.TraceLog.dll!Microsoft.VisualStudio.Diagnostics.Logging.QueuedIpcPipeClient.WaitForConnect() + 0x4b bytes    
Microsoft.VisualStudio.TraceLog.dll!Microsoft.VisualStudio.Diagnostics.Logging.QueuedIpcPipeClient.Add(byte* data = 0x2d16f4f0, int msgLen = 258) + 0x3d bytes    
Microsoft.VisualStudio.TraceDebugger.dll!Microsoft.VisualStudio.TraceDebugger.DebuggerEventRecorder.HandleModuleLoad(Microsoft.VisualStudio.TraceDebugger.ModuleLoadNotifyEvent moduleLoadNotifyEvent) + 0x119 bytes    
Microsoft.VisualStudio.TraceDebugger.dll!Microsoft.VisualStudio.TraceDebugger.ModuleLoadNotifyEvent.HandleNotifyEvent(Microsoft.VisualStudio.TraceDebugger.Debuggee debuggee) + 0x1c bytes    
Microsoft.VisualStudio.TraceDebugger.dll!Microsoft.VisualStudio.TraceDebugger.EngineNotifyHandler._NotifyHandleEvents(uint dwEventTicket = 32) + 0x121 bytes    
Microsoft.VisualStudio.TraceDebugger.dll!Microsoft.VisualStudio.TraceDebugger.EngineNotifyHandler.NotifyHandleEvents.AnonymousMethod__21() + 0xd bytes    
Microsoft.VisualStudio.TraceLog.dll!Microsoft.VisualStudio.Diagnostics.Common.ILExceptionFilter.Invoke(Microsoft.VisualStudio.Diagnostics.Common.ILExceptionFilter.InvocationTarget target, Microsoft.VisualStudio.Diagnostics.Common.ILExceptionFilter.FilterFunction predicate = {Method = Cannot evaluate expression because the current thread is in a sleep, wait, or join}, Microsoft.VisualStudio.Diagnostics.Common.ILExceptionFilter.HandlerFunction catchBlock = {Method = Cannot evaluate expression because the current thread is in a sleep, wait, or join}) + 0x29 bytes    
Microsoft.VisualStudio.TraceLog.dll!Microsoft.VisualStudio.Diagnostics.Common.ExceptionHelper.Invoke(Microsoft.VisualStudio.Diagnostics.Common.ILExceptionFilter.InvocationTarget target) + 0x56 bytes    


Disabling the VS Hosting process has certainly improved matters. I'll report back if I can repro with the hosting process disabled.
Posted by CoolDadTx on 11/10/2009 at 10:10 AM
It's taken a while but I've finally seen VS lock up again when going into debug even when the host process is disabled. I'm attaching the output window contents from debugging VS directly. As before, VS sits there for a while and periodically generates first chance exceptions. It eventually generates a few exceptions and recovers.

Out of curiosity I set the debugger to break when the exception 0xe0434352 was thrown because that is where VS seems to be sitting for a while. It was being thrown by the trace log infrastructure. I'm attaching the callstack from one such exception.
Posted by Jarem on 11/9/2009 at 7:54 AM
Having this problem as well. Win7 x64.
Posted by Ryan Mrachek on 11/8/2009 at 5:41 AM
This problem happens almost everytime for me. I'm running Win7 64 fairly clean with just the beat bits installed. I've made a process dump or two please let me know if you're interested.

btw- This problem is a road block for seriously using 2010.
Posted by CoolDadTx on 11/5/2009 at 8:18 PM
I've posted all the scenarios I see it in. It is reproducible by quite a few people and the debugger logs show exceptions and what appears to be timeouts in COM calls. Assuming your fixes involve those areas then it might be resolved but there is no real way to tell. I've seen it with VB and C# apps whether they were WinForms or WPF. They can be new or existing projects. The key seems to be continually stopping and restarting the debugger over time. It does seem to be related to the vshost process.

What can we do to better provide you the debugging information and/or verify that your solution solves the problem? I've sent the call stack and debugger output for the scenarios I've seen so hopefully they've helped you out some. Nevertheless this problem is not isolated to one person and it is a breaking issue that will prevent folks from upgrading. We need to make sure it is fixed before the final release. So whatever we can do to help we'll try.
Posted by Microsoft on 11/5/2009 at 3:36 PM
Hi,

We are currenly unable to reproduce this issue. We've made a few performance optimizations since Beta 2 and this may have solved your problem. Is there a specific solution that you see this with and would like for us to test out?

Thanks,
Visual Studio Debugger Team
Posted by CoolDadTx on 11/5/2009 at 6:55 AM
I've been running a day with the host disabled and haven't had any more lock ups. However I have experienced two other (potentially unrelated) issues.

Firstly I created a brand new C# WPF app. Before the designer even finished initializing to show me the main window VS hung. The host process had already been started. I hadn't seen it hang outside the debugger until this point.

Today I created a brand new VB WPF app and started into debug mode. The build succeeded and VS hung. What makes this a little different is that VS had created two host processes and two VSTraceLog processes whereas it normally only creates one when you first open/create the project.
Posted by David131 on 11/4/2009 at 11:15 AM
I disabled the hosting process and it does see to have an impact on the frequency of this problem. Once I did that though it now hangs sometimes when trying to start the debug process.
Posted by CoolDadTx on 11/4/2009 at 6:18 AM
Sorry for the delay. I've been in unmanaged land for a few days (which doesn't seem to exhibit the problem). I ran with the host enabled until the problem replicated. Then I disabled the host and continued running. It seemed to help although VS still had a noticeable delay. I'm going to run without the host for a day and see if the problem occurs again.
Posted by steveloft on 11/3/2009 at 12:59 PM
I get this problem too. VS 2010 hangs after debugging - mine is a WPF application. I have to use task manager to kill Visual Studio. Disabling the hosting process does make the problem go away.

Steve
Posted by Microsoft on 11/1/2009 at 10:50 PM
Hi -

Thanks for reporting this issue. We have not been able to reproduce this issue internally, so we will need to do some further investigation to see what is going on. As a starting point in the investigation, can you see if this issue also reproduces when you disable the Visual Studio Hosting Process? To disable this, go to Project Properties for the project you're debugging, go to the Debug tab, and all the way at the bottom you'll see a checkbox "Enable the Visual Studio hosting process." Can you uncheck this and see if the problem goes away? Let us know.

Thanks,
-- Izzy

Izzy Gryko
Lead Software Design Engineer
Microsoft Visual Studio Platform Development
izzyg@microsoft.com
Posted by Vector Hawk on 10/30/2009 at 8:29 AM
I also have this issue. My application uses a unbound DataGrid and several Drop Downs. After it freezes, I have to use Task Manager to terminate VS 2010.
Posted by David131 on 10/30/2009 at 7:49 AM
I am also experiencing this problem in VS2010 with a new WinForms application. It is happening several times an hour and usually requires terminating the VS2010 task and restarting the application. I have not been able to regain control of VS2010 after stopping the debug process.
Posted by Microsoft on 10/29/2009 at 12:36 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you
Sign in to post a workaround.
Posted by Andrew B Hall - MSFT on 12/1/2009 at 5:35 PM
Disable IntelliTrace:
-Open Tools->Options->IntelliTrace
-Uncheck "Enable IntelliTrace"
Posted by SimonKnight6600 on 8/5/2010 at 1:17 AM
Deleting the suo file fixes the problem, but it will come back again after you work with VS for some time...
Posted by Arjo Kalisvaart on 8/6/2010 at 9:27 AM
I am using VS2008 SP1 on a Windows XP X64 Professional workstation, and I encountered the same problem as described within this bug report. I was also experiencing the delays when I was closing one or all files, or closing the solution or closing VS2008 entirely.

The Workaround mentioned by SimonKnight6600 helped out and after having removed the .suo file solved the issue. I renamed the file and it is approximately 1Mb in size, so it is not an overwhelming large file. If need be I can upload the file in order for you to investigate the issue further.

Regards,
Arjo Kalisvaart.
Posted by Bernardo Salazar on 9/30/2011 at 3:43 PM
After a heavy research, and lost a big part of my hair, i found this:
•Tools -> Options
•Go to Debugger
•Uncheck "Enable property evaluation and other implicit function calls"

I disabled intellitrace, also.

This worked for me. I tested several times. I hope MS fix this someday.
Posted by Gary_Rock_ on 12/14/2011 at 3:49 AM

I got around my VS2010 debug hang issue by reloading from the solution directly from explorer and not loading it by hovering over the taskbar shortcut and clicking the previous project. It has gone from 10 mins back to a normal 1 or 2 seconds, exiting debug and the entering debug and build have gone back to a normal speed.

I'd be interested to know if others have found this too and if it is going to prove to be a temp fix?
© 2012 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement