Artsio

Bom dia! Depois de quebrar a cabeça a única maneira que consegui resolver foi editar o "ACBr_DFeComum" e acionar a função "DestroyLibXml2Interface()" da interface "ACBrLibXml2.pas" que libera a dll "LibXML2" da memória, nos "Destroy" das classes: "TACBrXmlDocument()" e "TDFeSSLXmlSignLibXml2"; Código que foi acrescentado: Unit: ACBrDFeXsLibXml2: destructor TDFeSSLXmlSignLibXml2.Destroy; begin DestroyLibXml2Interface(); inherited Destroy; end; Unit: ACBrXmlDocument: destructor TACBrXmlDocument.Destroy; begin if xmlRootElement <> nil then xmlRootElement.Free; if xmlDocInternal <> nil then xmlFreeDoc(xmlDocInternal); DestroyLibXml2Interface(); inherited Destroy; end; Sei que o "DestroyLibXml2Interface()" já é chamado no finalization da unit "ACBrLibXml2". Seja o que for por uso de thread, concorrência, as chamadas seguintes para o endereço de memória dessa dll compartilhada estão dando violação de endereço memória, e causam os retornos de leitura vazia do xml. Talvez vcs poderiam criar um branch para com o carregamento estático dessa dll, para testar.

Nos meus testes aqui consegui ver que está carregando a dll dinamicamente "libxml2.dll" na memória Só quando vai chamar a função "loadedDoc := xmlParseDoc(PAnsiChar(ansistring(AXmlDocument))); dá o erro 15/08/2024 17:07:56: "TACBrXmlDocument.LoadFromXml" : Linha: 1351 15/08/2024 17:07:56: LibXml2File: C:\_ROTUMA\FGE\WIN32\libxml2.dll 15/08/2024 17:07:56: "TACBrXmlDocument.LoadFromXml" : Linha: 1356 15/08/2024 17:07:56: "TACBrXmlDocument.LoadFromXml" : Exception: Access violation at address 7728F953 in module 'ntdll.dll'. Write of address 00000014 15/08/2024 17:07:56: "TACBrXmlDocument.LoadFromXml" : Linha: 1384 procedure TACBrXmlDocument.LoadFromXml(AXmlDocument: string); var loadedDoc: xmlDocPtr; loadedRoot: xmlNodePtr; begin LogSalvar('"TACBrXmlDocument.LoadFromXml" : Linha: 1351'); // a linha abaixo foi comentada pois segundo o DSA consome muito a CPU e causa lentidão // AXmlDocument := NativeStringToUTF8(AXmlDocument); try LogSalvar('LibXml2File: '+LibXml2File); LogSalvar('"TACBrXmlDocument.LoadFromXml" : Linha: 1356'); loadedDoc := xmlParseDoc(PAnsiChar(ansistring(AXmlDocument))); LogSalvar('"TACBrXmlDocument.LoadFromXml" : Linha: 1358'); except on E: Exception do LogSalvar('"TACBrXmlDocument.LoadFromXml" : Exception: '+e.Message); end; if loadedDoc <> nil then begin xmlFreeDoc(xmlDocInternal); xmlDocInternal := loadedDoc; loadedRoot := xmlDocGetRootElement(xmlDocInternal); if loadedRoot <> nil then begin xmlRootElement.Free; xmlRootElement := TACBrXmlNode.Create(Self, loadedRoot); end else begin raise EACBrXmlException.Create(xmlGetLastError()^.message); end; end else begin raise EACBrXmlException.Create(xmlGetLastError()^.message); end; end;

Tem alguma ideia que possa estar testando se esta dll está sendo carregada? Ou que possa estar fazendo para descubrir a origem do problema?

Não tive tempo de testar no exemplo, mas vou ver se consigo simular algo parecido com o nosso. Testei no Síncrono e Assíncrono e também ocorre.

Aqui no nosso Sistema, as bpls e dlls, são todas carregadas dinamicamente, tem esse detalhe, pode ser por isso. Só está ocorrendo na NFCe, os xml de retorno estão certo, voltando correto, mas por algum motivo não consegue pegar os dados na leitura do xml de retorno. (CStats, Protocolo, estão vazios) Se eu fechar a tela depois do erro, e abrir novamente e dar consulta, retorna o status e protocolo, correto. Se tivesse uma função, por exemplo: "Refresh" no componente, ou algo assim para liberar da instância de memória os atributos que carregou a dll com violação de memória, Daria para usar o consultar para pegar o retorno.

Qual a alternativa que vcs propõe, já por conta desse Bug, pois no meu projeto, limpei td do ACBr na máquina, dll, e recompilei e nada. Continua dando esse problema de retorno vazio na NFCe, que internamente é um action violation ntdll.dll?

Qual era a dll anterior que estava sendo usada? Pois pelo visto esta dll libxml2.dll tá dando problema com capicom.dll pois o sistema nosso não funciona nem a pau com WinCrypt, e olha que já testamos em várias maquinas de clientes foram mais de 10, e não funciona. Até assinamos na época o ACBrPro e não foi de ajuda. Poderiam ter deixado como configuração para retrocompatibilidade, porque agora ferrou de vez. Tem mais de 400 notas pendentes de clientes...

Pude constatar através dos logs que houve alterações nessas funções de leitura do xml... Para mim é essa classe TACBrXmlDocument que está com algum problema TACBrXmlDocument ?

No meu limpei todas dll e com WinCrypt não funciona nada, Mas esses erros estão correndo na leitura do retorno do xml. Para mim descubrir o "Action Violation" tive que entrar no código fonte do ACBr na unit " ACBrNFe.RetConsSit", onde adicionei o exception e salvei num logo para descobrir o erro, senão tava procurando vento. function TRetConsSitNFe.LerXml: Boolean; var Document: TACBrXmlDocument; ANode, ANodeAux: TACBrXmlNode; ANodeArray: TACBrXmlNodeArray; ok: Boolean; i: Integer; Item : TRetEventoNFeCollectionItem; begin Document := TACBrXmlDocument.Create; try try Result := False; if XmlRetorno = '' then Exit; Document.LoadFromXml(XmlRetorno); ANode := Document.Root; if ANode <> nil then begin versao := ObterConteudoTag(ANode.Attributes.Items['versao']); verAplic := ObterConteudoTag(ANode.Childrens.FindAnyNs('verAplic'), tcStr); tpAmb := StrToTpAmb(ok, ObterConteudoTag(ANode.Childrens.FindAnyNs('tpAmb'), tcStr)); cUF := ObterConteudoTag(ANode.Childrens.FindAnyNs('cUF'), tcInt); nRec := ObterConteudoTag(ANode.Childrens.FindAnyNs('nRec'), tcStr); cStat := ObterConteudoTag(ANode.Childrens.FindAnyNs('cStat'), tcInt); xMotivo := ObterConteudoTag(ANode.Childrens.FindAnyNs('xMotivo'), tcStr); dhRecbto := ObterConteudoTag(ANode.Childrens.FindAnyNs('dhRecbto'), tcDatHor); chNFe := ObterConteudoTag(ANode.Childrens.FindAnyNs('chNFe'), tcStr); case cStat of 100, 101, 104, 110, 150, 151, 155, 301, 302, 303: begin ANodeAux := ANode.Childrens.FindAnyNs('protNFe'); if ANodeAux <> nil then begin // A propriedade XMLprotNFe contem o XML que traz o resultado do // processamento da NF-e. XMLprotNFe := ANodeAux.OuterXml; ANodeAux := ANodeAux.Childrens.FindAnyNs('infProt'); if ANodeAux <> nil then begin protNFe.tpAmb := StrToTipoAmbiente(ok, ObterConteudoTag(ANodeAux.Childrens.FindAnyNs('tpAmb'), tcStr)); protNFe.verAplic := ObterConteudoTag(ANodeAux.Childrens.FindAnyNs('verAplic'), tcStr); protNFe.chDFe := ObterConteudoTag(ANodeAux.Childrens.FindAnyNs('chNFe'), tcStr); protNFe.dhRecbto := ObterConteudoTag(ANodeAux.Childrens.FindAnyNs('dhRecbto'), tcDatHor); protNFe.nProt := ObterConteudoTag(ANodeAux.Childrens.FindAnyNs('nProt'), tcStr); protNFe.digVal := ObterConteudoTag(ANodeAux.Childrens.FindAnyNs('digVal'), tcStr); protNFe.cStat := ObterConteudoTag(ANodeAux.Childrens.FindAnyNs('cStat'), tcInt); protNFe.xMotivo := ObterConteudoTag(ANodeAux.Childrens.FindAnyNs('xMotivo'), tcStr); protNFe.cMsg := ObterConteudoTag(ANodeAux.Childrens.FindAnyNs('cMsg'), tcInt); protNFe.xMsg := ObterConteudoTag(ANodeAux.Childrens.FindAnyNs('xMsg'), tcStr); end; end; end; end; retCancNFe.cStat := 0; if cStat in [101, 151, 155] then begin ANodeAux := ANode.Childrens.FindAnyNs('infCanc'); if ANodeAux <> nil then begin retCancNFe.tpAmb := StrToTpAmb(ok, ObterConteudoTag(ANodeAux.Childrens.FindAnyNs('tpAmb'), tcStr)); retCancNFe.verAplic := ObterConteudoTag(ANodeAux.Childrens.FindAnyNs('verAplic'), tcStr); retCancNFe.cStat := ObterConteudoTag(ANodeAux.Childrens.FindAnyNs('cStat'), tcInt); retCancNFe.xMotivo := ObterConteudoTag(ANodeAux.Childrens.FindAnyNs('xMotivo'), tcStr); retCancNFe.cUF := ObterConteudoTag(ANodeAux.Childrens.FindAnyNs('cUF'), tcInt); retCancNFe.chNFe := ObterConteudoTag(ANodeAux.Childrens.FindAnyNs('chNFe'), tcStr); retCancNFe.dhRecbto := ObterConteudoTag(ANodeAux.Childrens.FindAnyNs('dhRecbto'), tcDatHor); retCancNFe.nProt := ObterConteudoTag(ANodeAux.Childrens.FindAnyNs('nProt'), tcStr); end; end; if Assigned(procEventoNFe) then procEventoNFe.Free; procEventoNFe := TRetEventoNFeCollection.Create; try ANodeArray := ANode.Childrens.FindAllAnyNs('procEventoNFe'); if Assigned(ANodeArray) then begin for i := Low(ANodeArray) to High(ANodeArray) do begin AnodeAux := ANodeArray[i]; Item := procEventoNFe.New; Item.RetEventoNFe.XmlRetorno := AnodeAux.OuterXml; Item.RetEventoNFe.XML := AnodeAux.OuterXml; Item.RetEventoNFe.LerXml; end; end; finally Result := True; end; end; // Result := True; except on E: Exception do begin {$IFDEF TESTAR} LogSalvar('"TRetConsSitNFe.LerXml" : Exception: ' + E.Message); {$ENDIF} Result := False; end; end; finally FreeAndNil(Document); end; end; Adicionei esse código... {$IFDEF TESTAR} LogSalvar('"TRetConsSitNFe.LerXml" : Exception: ' + E.Message); {$ENDIF}

Já usei exemplo de TD a forma possível, e o problema está nessa função LerXml que é uma função interna do ACBr. Seja como for seria bom vcs darem uma revisão nessa função... Atualizei umas 10 vezes, desde esse problema e nada... Fiz atualização dll, schemas, td que é possível e nada

Usei o WinCrypt tempo atrás e não deu certo, até aqui na empresa pagamos pelo ACBrPro e não ajudou com a questão da dll ntdll.dll Seja como for depois dessas últimas alterações do ACBr que foi mexido na leitura do XML, esse bug apareceu, deve ter alguma pecualidade com essas mudanças no LerXml qdo é NFCe, vi pelos logs de atualizações até tem uma mudança com função "ParseText"

Indo mais a fundo no método LerXml, editei e implementei o "Exception" que não tinha, salvando em um arquivo e tudo indica parece que é problema com nessa "ntdll.dll" do windows 13/08/2024 21:11:03: "TRetConsSitNFe.LerXml" : Exception: Access violation at address 7756F953 in module 'ntdll.dll'. Write of address 00000014 Estou usando o Capicom, pois nos outros ficava parecendo esse mesmo erro da dll "ntdll.dll" E esse problema só está dando na NFCe. Na NFe, CTe está enviando e recebendo normal. Pode ser que está aparecendo no meu porque uso de forma RunTime carrego as bpls td junto

Procurei no meu código e não achei nada mudando o ambiente, esse erro de ambiente "1" é porque está vazio. Tem algum bug ou problema no ACBr que ele não consegue lerXml de retorno, e dá vazio e lança a exceção. Fui direto ao fonte e rastreei o seguinte: 13/08/2024 18:24:14: "TNFeRecepcao.TratarResposta" : <retConsSitNFe versao='4.00' xmlns='http://www.portalfiscal.inf.br/nfe'> <tpAmb>2</tpAmb> <verAplic>PR-v4_4_68</verAplic> <cStat>104</cStat> <xMotivo>Lote processado</xMotivo> <cUF>41</cUF> <dhRecbto>2024-08-13T18:24:13-03:00</dhRecbto> <protNFe versao='4.00'><infProt Id='ID141240000378909'> <tpAmb>2</tpAmb> <verAplic>PR-v4_4_68</verAplic> <chNFe>41240807424383000174650060000000591000000609</chNFe> <dhRecbto>2024-08-13T18:24:13-03:00</dhRecbto> <nProt>141240000378909</nProt> <digVal>N/ZKUSxH1TH3cwgaU4+g438XDQw=</digVal> <cStat>100</cStat><xMotivo>Autorizado o uso da NF-e</xMotivo> </infProt> </protNFe> </retConsSitNFe> 13/08/2024 18:24:14: "TNFeRecepcao.TratarResposta" FcStatus: 0 Ambiente e status estão certo. Por algum motivo no método "LerXml" ele não consegue pegar os dados, e dá vazio.

No xml retorno aparece certo <retEnviNFe xmlns="http://www.portalfiscal.inf.br/nfe" versao="4.00"> <tpAmb>2</tpAmb> <verAplic>PR-v4_4_68</verAplic> <cStat>104</cStat> <xMotivo>Lote processado</xMotivo> <cUF>41</cUF> <dhRecbto>2024-08-13T14:46:52-03:00</dhRecbto> <protNFe versao="4.00"> <infProt Id="ID141240000377990"> <tpAmb>2</tpAmb> <verAplic>PR-v4_4_68</verAplic> <chNFe>41240807424383000174650060000000531000000540</chNFe> <dhRecbto>2024-08-13T14:46:52-03:00</dhRecbto> <nProt>141240000377990</nProt> <digVal>2dtWccDWYMDob/g8ypBzjCWkq74=</digVal> <cStat>100</cStat> <xMotivo>Autorizado o uso da NF-e</xMotivo> </infProt> </protNFe> </retEnviNFe> Só se tiver perdendo algum dado na memória na hora da recepção. Mas tem alguma ideia do que pode ser?